Log file Viewer
#pypa logs for Wednesday the 18th of March, 2020
[15:52:08] <gnomeza> Hi #pypa. How do I create a reproducible environment for an application packaged as a wheel?
[15:52:46] <gnomeza> The concrete requirements are within the wheel (a requirements.txt) but METADATA has the (abstract) requirements from install_requires...
[15:56:17] <gnomeza> Maybe what I want to do is tell pip to generate the wheel METADATA from requirements.txt somehow?
[16:45:18] <tos9> gnomeza: you mean you want to have a way to install your package without an index that uses the package versions from your requirements file?
[16:45:56] <tos9> gnomeza: METADATA is an internal implementation detail of the wheel format, so definitely nothing in there is relevant, though it sounds like maybe you're just bringing that up to note that what you did already didn't give you the versions you expected?
[17:02:16] <gnomeza> tos9: yes - I'm trying to deploy an app from its wheel. But I'm trying to get the same environment (which specific requirements) each time.
[17:02:39] <gnomeza> Those requirements are frozen (within the sdist and the wheel) in its requirements.txt.
[17:03:19] <gnomeza> I can't see a way to get at the requirements.txt without installing (or unzipping) the wheel. Which seems wrong.
[17:04:38] <gnomeza> The only other way I can think of is to make the install_requires concrete... (matching the requirements.txt) but that is problematic for all the usual reasons
[17:06:44] <gnomeza> dude-x: the requirements.txt is already generated at build time using `pip freeze -l` within the (isolated, PEP517) build venv
[17:07:30] <dude-x> pipdeptree can show you dependencies, if you want to figure out other packages dependencies
[17:07:35] <gnomeza> I'm just getting the feeling that my whole approach here is wrong and that wheels aren't supposed to be used this way.
[17:54:39] <tos9> gnomeza: yeah so the approach for that is use `pip wheel -r requirements.txt` to get a folder with all the right versions
[17:55:04] <tos9> gnomeza: then drop that folder onto your server or wherever and use `pip install --no-index --find-links thatunpackedfolder yourpackage`
[17:55:25] <tos9> and then the versions you get are the wheels that will have been fetched from step 1, and correspond to your requirements file
[17:56:38] <tos9> there are slightly more sophisticated versions of this if you want to look into them, they revolve around packaging up that folder into a fat binary, and these days are built on the zipapp module in the stdlib, but shiv and pex are 2 things on top of that -- look into them and decide for yourself if you want to head down this route, but my personal position is they're still not easy enough to justify in
[17:57:42] <gnomeza> tos9: thanks. I hoped that wasn't the case - makes deployment a bit heavyweight when we'd otherwise be pulling dependencies from our private pypi.
[17:59:00] <tos9> gnomeza: I hope you don't work for my ops team :) -- but yeah such is life for better or worse I think.
[17:59:45] <tos9> and then you just grab that output folder and plop it on servers, and they never need to talk to your private PyPI
[18:01:46] <gnomeza> tos9: this client of mine barely has an ops team. But what they do have, thanks to my efforts, is 30 python libs and a handful of python apps instead of one big mess of python code full of `sys.path.append`
[18:05:34] <gnomeza> How about this as a compromise (skipping a few obvious steps): `pip freeze -l > requirements.txt && git commit requirements.txt && git tag release-X`
[18:05:45] <gnomeza> Then deployment: `git clone; git checkout release-X; pip install -r requirements.txt`
[18:06:21] <gnomeza> This would apply to the apps only, naturally. Not the libs which would still be pulled from the internal pypi
[18:21:30] <tos9> gnomeza: other than the pip freeze step what you just described is what I consider the "standard" deployment model for when a git repo is involved
[18:21:56] <tos9> it's non-ideal for the reasons you know and can guess but there are hundreds if not thousands of deployments that work that way certainly
[18:23:27] <DREAMINCODER_202> Hello guys! I am Satvik G S from India pursuing first year CS Engineering.I am willing to contribute and I dont have any idea what's going on right now!could somebody help me please?
[20:10:51] <techalchemy> toad_polo, are there plans to deprecate 'setup.py test' soon? is that gone yet?