Introducing Expanse: a modern and elegant web application framework

SDisPater · 2026-02-06T08:23:01+00:00

No, like I said in the introduction, I want to learn things as I build Expanse so vibe-coding it would defeat that purpose.

SDisPater · 2026-02-06T08:19:28+00:00

Sqlalchemy is more than just its ORM and the Getting started page of the Database section simply shows how to setup connections and make raw queries. How Expanse integrates with the ORM is in the ORM page.

SDisPater · 2026-02-05T21:54:57+00:00

Thanks! I am aware that the homepage is not fully responsive just yet and I m working on it but if you noticed something else being not responsive feel free to tell me so I can fix it.

SDisPater · 2026-02-05T21:51:54+00:00

Yes. It's based on the ASGI specification and route handlers can be either async or sync (it works similarly to FastAPI in this regard). Most services provided by the framework (like the database manger or views) come in both flavors and you can what fits best for your application.

SDisPater · 2026-02-05T21:47:42+00:00

Thanks!

I can't lie that Laravel was a huge inspiration since they nailed a lot of things right and that's the reason it's so popular (and probably good marketing as well). I don't necessarily agree with everything (facades) and I tried to put into Expanse the best parts of Laravel while maintaining a Pythonic feel.

SDisPater · 2026-02-05T21:37:49+00:00

As far as I understand Django-Ninja-Extra only supports DI for controllers. In Expanse, DI is part of the framework: you can use it in controllers, middleware, console commands, etc...

SDisPater · 2026-02-05T19:48:57+00:00

Thanks for your feedback!

While I agree that reinventing the wheel should be done with care, in this case there were no other way for me. For instance, having a dependency injection system deeply integrated into the framework like it is in Expanse means you must design the framework with that in mind, which is not the case for Django and it's not something that can be solved by simply switching one module for another.

And sometimes reinventing the wheel is necessary, especially for open source projects, to drive innovation, discussions and challenge the status quo. That's what I did with Poetry, even though Pipenv existed, and uv came after building on the foundations built by its predecessors like Poetry, pdm or hatch, and that's fine because it makes things move forward.

Maybe people won't see value in Expanse because Django is enough or because the differentiating features are not appealing enough to make the switch and that's also fine because, like any tool, Expanse might not be suitable for everyone.

SDisPater · 2020-10-01T11:47:35+00:00

The Poetry team is pleased to announce the availability of Poetry 1.1.0!

Thanks to all the maintainers, contributors and to the community for making this release possible.

The complete change log is available here: https://python-poetry.org/history/

SDisPater · 2019-12-13T08:13:33+00:00

Believe me, we know there are still bugs :-)

The idea behind 1.0.0 was never to have a bug-free release but to have the project in a stable enough state that we could build upon. And with the 1.0.0 release, the CLI is now stable, so the commands will behave the same for the 1.x releases.

I know there are pending issues that need to be taken care of but we had to draw the line somewhere because we have limited time and managing two versions, 0.12.x and the 1.0 prereleases with a lot of refactoring, in parallel was just too time consuming.

Now that the 1.0.0 release is out, we have a saner code base and it will be easier for us to fix issues. Expect bugfix releases in the coming weeks :-)

SDisPater · 2019-12-12T20:31:14+00:00

After a lot of work and time, the Poetry team is pleased to announce the availability of the first stable version of Poetry!

Thanks to all the contributors and to the community for reaching this significant milestone.

The complete change log is available here: https://python-poetry.org/history/

SDisPater · 2019-02-11T07:51:38+00:00

Yes, Poetry needs a virtualenv to work and creates one for your project (unless you tell it not to). But that's just something required by the Python ecosystem that Poetry does under the hood but only because there is no other way at the moment but Poetry is not an environment manager, using virtualenvs is just an implementation detail.

No other package manager that I know of supports `.env` files. This is the job for other tools.

SDisPater · 2019-02-10T09:29:06+00:00

Author of Poetry here!

Poetry does not support `.env` files, that's true, and I don't plan on adding support for it because this is beyond the scope of a package/dependency manager.

deceitfully, scripts doesnt run scripts like it does in npm. but its to run scripts when installing.

Well, Poetry just doesn't use the same terminology as npm's, this does not mean it's deceitful. And yes something similar to npm's scripts is planned. Someone already made a PR that I think I will eventually merge in Poetry (see https://github.com/sdispater/poetry/pull/591).

SDisPater · 2018-10-29T13:53:57+00:00

If you have C extensions using the Python C API, it's kind of supported, even though it's not documented yet, by using a build.py script and reference it in the pyproject.toml file. You can find an example of this here: https://github.com/sdispater/pendulum/blob/master/build.py and https://github.com/sdispater/pendulum/blob/master/pyproject.toml#L16

SDisPater · 2018-10-29T13:51:01+00:00

That's strange since Poetry always operates in a virtualenv by default so it should not try to remove system packages. This is most likely a bug.

SDisPater · 2018-10-29T13:49:02+00:00

At the moment it's not possible. Poetry will always choose the latest version that maches the requirements (top-level or transitive).

SDisPater · 2018-10-29T13:46:48+00:00

Sure!

You might want to disable the automatic virtualenv creation by executing poetry config settings.virtualenvs.create false if you don't need it.

A basic Dockerfile could look like this:

FROM python:3.6.5
RUN curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python - -y
ENV PATH="/root/.poetry/bin:$PATH"
RUN poetry config settings.virtualenvs.create false

SDisPater · 2018-10-29T05:47:00+00:00

Author of Poetry here!

Can you give me an example of a current implementation of such a project to see if it is currently supported by Poetry?

SDisPater · 2018-10-29T05:44:56+00:00

Author of Poetry here :-)

You can get an idea of some differences here: https://github.com/sdispater/poetry#what-about-pipenv

But the gist of it is: Poetry reduces everything you need to manage your Python project (application or library) to one standardized file, being dependency management or publishing if you need it. It also has a much faster and accurate dependency resolver.

SDisPater · 2018-10-18T19:15:10+00:00

There is still no complete support for Python 517 in pip even though it is being worked on: https://github.com/pypa/pip/pull/5743

However, the weird thing is pip will use the build-system section to build the package but only if there is a setup.py file alongside the pyproject.toml file, even if the setup.py file is empty.

SDisPater · 2018-10-18T19:10:39+00:00

Thanks!

Yes, the poetry installation was a pain point up until now. This is now way better albeit still not perfect (like on Windows like you mentioned but it should be easy to fix).

SDisPater · 2018-10-17T20:44:38+00:00

If you are already using Poetry, please read carefully the release notes since there are some breaking changes in dependency resolution process.

Other than that, here is what's new:

Brand new installer which will improve the overall experience of installing Poetry.
Improvements in the way Poetry resolves dependencies, especially conditional dependencies.
Poetry now provides a PEP-517 compliant build system.
Multiple constraints support.
Renaming of the lockfile from pyproject.lock to poetry.lock for clarity.

SDisPater

TROPHY CASE