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
pythonPackages.pex: 1.2.7 -> 1.4.5 #45497
Conversation
Okay... I guess this is a hint that moving pex does have an impact :-) |
Do you know if it is used as an executable or as a library in |
@@ -0,0 +1,29 @@ | |||
{ stdenv, python3Packages }: | |||
with python3Packages; buildPythonApplication rec { | |||
name = "${pname}-${version}"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drop this line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, thanks -- is it computed automatically from pname
and version
?
pkgs/top-level/all-packages.nix
Outdated
@@ -7620,6 +7620,7 @@ with pkgs; | |||
|
|||
pew = callPackage ../development/tools/pew {}; | |||
pipenv = callPackage ../development/tools/pipenv {}; | |||
pex = callPackage ../development/tools/pex {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alphabetic order and blank lines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've inserted the package between pew
and pipenv
now.
patches = [ ./set-source-date-epoch.patch ]; | ||
|
||
# A few more dependencies I don't want to handle right now... | ||
doCheck = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you check whether these dependencies have been packaged in the meantime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I just copied the existing definition. Removing the line seems to work fine -- though no tests are run.
Please let me know how you like to see changes made in response to review comments: as follow-up commits, or by me immediately fixing the broken commit and force pushing?
@Mic92, I looked it up and Pants do use PEX as a Python library. So I guess that means that I should not be moving from |
Yes otherwise pantsbuild might break because no dependencies from pex to pantsbuild are propagated: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/python-packages.nix#L66 @FRidh would it make sense to have also a |
I don't really see the value in having a |
Oh, I don't know if there's any value in it either :-) I just saw that Pipenv was packaged that way and since PEX is also a command line too, I thought that using I'll try updating it back to |
propagatedBuildInputs = [ setuptools wheel requests ]; | ||
|
||
prePatch = '' | ||
substituteInPlace setup.py --replace 'SETUPTOOLS_REQUIREMENT,' '"setuptools",' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little worried about this line -- which was part of the original derivation. The setup.py
file from pex includes a pex/version.py
file, which says:
# NB: If we upgrade to setuptools>=34 pex's bootstrap code in `PEXBuilder` will need an update to
# include the `packaging` package in the `.bootstrap/` code since we use
# `packaging.specifiers.SpecifierSet` - indirectly - through `pkg_resources.Requirement.specifier`.
SETUPTOOLS_REQUIREMENT = 'setuptools>=20.3,<34.0'
WHEEL_REQUIREMENT = 'wheel>=0.26.0,<0.32.0'
The SETUPTOOLS_REQUIREMENT
and WHEEL_REQUIREMENT
variables are then used in setup.py
. When we change the requirement to just "setuptools"
, we get whatever version is in Nix -- version 40.0.0 at the moment. This sounds dangerous in light of the above comment.
Is there a normal approach in Nix to handle situations like this? I imagine one could package setuptools version 33 and have pex use that specific version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With python we are more bound to having only a single version in nixpkgs because of dependency propagation. However it seems that master also support setuptools newer then 34: https://github.com/pantsbuild/pex/blob/f125317bb6001ccbb56f68168bc45f947d274405/pex/version.py#L8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, cool! The new version.py
file says:
# Versions 34.0.0 through 35.0.2 (last pre-36.0.0) de-vendored dependencies which
# causes problems for pex code so we exclude that range.
SETUPTOOLS_REQUIREMENT = 'setuptools>=20.3,<41,!=34.*,!=35.*'
which means that using version 40.0.0 should be fine. Thanks for looking this up!
@GrahamcOfBorg build pythonPackages.pex python3Packages.pex |
Success on x86_64-darwin (full log) Attempted: pythonPackages.pex, python3Packages.pex Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: pythonPackages.pex, python3Packages.pex Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: pythonPackages.pex, python3Packages.pex Partial log (click to expand)
|
}; | ||
|
||
propagatedBuildInputs = [ setuptools wheel requests ]; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blind guess:
checkInputs = [ pytest ];
to fix the build issues:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'll give it a try..
The install_requires have changed from version 1.2.7 to 1.4.5 and now also include the wheel package. So this and setuptools have been added to propagatedBuildInputs.
The files in /nix/store are all back-dated to 1970, and this breaks pex when it tries to generate wheels: wheels are really zip files, and the zip file format does not support dates before 1980. This is normally handled by setting SOURCE_DATE_EPOCH when building the Nix package. However, pex will invoke further Python interpreters at runtime in calls like this: $ python setup.py bdist_wheel We thus need to ensure that it passes the SOURCE_DATE_EPOCH variable onto those interpreters. The date of the wheels will be fixed at 1980.
Without requests, pex will emit a number of warnings to the terminal when building pex files: % ./result/bin/pex -v httpie -o http pex: Warning, using a UrllibContext which is known to be flaky. pex: Please build pex with the requests module for more reliable downloads. pex: Warning, using a UrllibContext which is known to be flaky. pex: Please build pex with the requests module for more reliable downloads. This fixes these warnings.
@GrahamcOfBorg build pythonPackages.pex python3Packages.pex |
Success on x86_64-darwin (full log) Attempted: pythonPackages.pex, python3Packages.pex Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: pythonPackages.pex, python3Packages.pex Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: pythonPackages.pex, python3Packages.pex Partial log (click to expand)
|
we also have |
You can reproduce these problems locally, when enabling nix's sandbox. |
Thanks @Mic92 -- I'll have to experiment a bit more with this offline! You're completely right that I should get my local setup done so that I can find a way to reproduce what you see. I'll ping you guys later when I have worked out the kinks... thanks for all the feedback until now! |
Hi guys -- I no longer work with Nix, so I won't be able to finish this. I hope the PR can be useful to someone else who wants to upgrade PEX. |
Motivation for this change
This packages a new version of pex and moves it to a top-level tool, similarly to how Pipenv is packaged.
I'm not sure what the impact is of the move from
pkgs/top-level/python-packages.nix
topkgs/top-level/all-packages.nix
, but since pex is more of a command line tool than a Python library, the change makes sense to me :-) Please advice if this is bad for some reason or if there is followup work to be done!The packaging was tested locally on a MacOS machine and a Ubuntu VM. The packaging was also executed on a Hydra installation with the sandbox enabled.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)