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
poetry2nix: init at 1.1.0 #76646
poetry2nix: init at 1.1.0 #76646
Conversation
@GrahamcOfBorg build poetry |
While I think it is great for developers to be able to use Poetry in Nix for creating reproducible environments and applications (I will be using it myself), I am a bit skeptical towards using it in Nixpkgs. Lock files make it quick and easy to package exactly what upstream intended, however, that's not always good. For example, they pin patch versions which means distributing security updates becomes harder. That, along with reporting to upstream issues we encounter is I think an important role of distributions. Clearly, this remark isn't just applicable to poetry2nix but also other such converters as well as Docker images. |
While this is true there is nothing that says we need to use uptreams lock files, throwing away upstream's lock-file and running Another thing about this: There are a lot of applications out there with complex dependency graphs that I will never package in nixpkgs without |
69f7607
to
1f40362
Compare
We could also use poetry2nix to maintain the current python packages set. The more we can move towards pure data in nixpkgs, the more it will allow us to write higher-level tooling to automate all the grunt work. In the future, GitHub will be mostly used by bots talking to each-other while we sip margaritas at the beach (or do other more interesting things than manual dependency resolution). |
This is a good idea I think. So long-term we need a way to regenerate (all) lock files and make them use the latest patch releases.
Clearly. For these kinds of applications it just does not make sense to use only the main packages set.
We could start a thread about this on Discourse but I can tell you already now it will fail with version conflicts when resolving dependencies (locking). Like now a way is needed to handle such situation. |
a6da5d6
to
6195894
Compare
I consider this merge-ready. |
@GrahamcOfBorg build poetry |
This is great! Makes me want to introduce poetry in all my python projects. Is there any chance however that this did break |
@knedlsepp Nope, nothing in |
@adisbladis: Oh. Sorry about that, I only noticed that it did break somewhere between |
One of our macOS Travis jobs seems to be broken since this got merged. The error is:
|
@asymmetric I suggest upgrading your nix version to 2.1 or newer. |
Why is poetry2nix being evaluated at all? That sounds bad for performance.. |
here is a back-compat for fromTOML that uses IFD: https://github.com/nmattia/naersk/blob/7f30aa64ce25959b0872012d990060016ae64f88/builtins/default.nix#L12-L34 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/future-of-npm-packages-in-nixpkgs/14285/3 |
Motivation for this change
This adds poetry2nix to nixpkgs and uses it to re-package
poetry
.This new poetry derivation has a number of advantages over the old one:
Prevents clashes between nixpkgs
poetry
and projects dependenciespoetry
's own lock filesThis ensures a well-tested set of dependencies.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @zimbatm @gilligan @andir