-
-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintenance: Looking for maintainers #1865
Comments
Thank you very much for your work on poetry2nix and its successors! |
While I have enjoyed working on and helping maintain poetry2nix, I'm migrating my main motivation for its use to uv2nix, and so will also not be able to do much more here beyond merging the occasional PR. Thanks for all your work here @adisbladis! |
I'm also migrating my main stack to uv2nix the first chance I get, Also @adisbladis work on uv2nix & pyproject.nix has just been stellar. As for an override collection, come join the effort at https://github.com/TyberiusPrime/uv2nix_hammer_overrides/ which is an outgrowth of my stalled PR #1742, done better this time around. edit: "first chance I get' probably means once nixpkgs 24.11 containing a newish uv is released. |
Can we maybe get some sort of basic maintenance going? |
This would be super helpful! Also happy to assist with basic MRs |
I can take over maintenance over the next few months since I depend on poetry2nix for thymis , at least until this whole python packaging thing is stabilized |
It's great that people are willing to step up to merge PRs and keep things on life-support, but I'm struggling with one very important point when it comes to delegation: trust. @Nebucatnetzer has a handful contributions over a longer period of time. I've invited you to the nix-community org and added you to the poetry2nix team. |
I know what you mean, I have been thinking about that as well but more in general as Nix is such a small community and there is so much to do. Anyway I think I can vouch for @elikoga as I have met him twice in person. Once at NixCon and then again in Rapperswil at the ZHF event. |
We will rely on poetry2nix either way and I'd like to see some of the PRs merged so I can get rid of my current brittle overrides. I think a good approach is for us to maintain a fork for us to get acquainted and we can pass maintenance of the nix-community repo around however feels useful |
I didn’t have the time yet to look at it but I don’t see a problem inviting you as an additional maintainer unless someone is really opposed to it. |
Ah never mind I don't have the rights to do that but if you @elikoga submit merge requests or review more complex merge requests I would really appreciate it. |
I'm no longer using Poetry or Poetry2nix, and want to step down from poetry2nix maintenance.
Poetry has a number of upcoming large changes, which poetry2nix is unlikely to gain support for:
There are a number of poetry2nix specific challenges long-term:
Dependency solving isn't very good
I started working on that in https://github.com/adisbladis/poetry2nix-v2, but with
uv
gaining a lock file I don't see the point any more.Nixpkgs Python builders aren't good
They should be replaced by https://pyproject-nix.github.io/pyproject.nix/build.html.
The whole API is misdesigned
mkPoetry*
shouldn't exist. A python2nix tool should generate an overlay to use with environment composition primitives.See
uv2nix
for prior art.Having a default choice between
sdist
orwheel
was a mistake. Users should be responsible for making this choice themselves as it shapes your entire user experience.Overrides
This is my biggest annoyance in regards to maintenance, and was kind of accidental.
I don't think python2nix tooling should come with overrides that taper over lock file deficiencies.
Overrides are ephemeral in nature and bit-rot.
It's better that external projects to take on this role, and let python2nix tooling focus on getting the semantics right.
Options
Switching to
uv
My personal recommendation is to use
uv
&uv2nix
instead.Uv2nix is still marked as experimental and might still undergo some breaking API changes, so this has some risks attached.
Sticking with Poetry
Using nixpkgs dependencies
If you're OK with using the Python package set from nixpkgs (ignoring
poetry.lock
) pyproject.nix is an option with it's Poetry pyproject.toml loader.This option is maintained and offers a migration path from Poetry to PEP-621.
Using dependencies from poetry.lock
This is not currently a maintained use case anywhere.
Pay for maintenance
I'm open for contract work.
The text was updated successfully, but these errors were encountered: