First a bit of background: one of our packages (porespy) is meant to be a simple library people can use on top of other packages like skimage, etc. We have so far avoided putting hard dependencies into our requirements so that our package will play nice with any others that are installed. However, I was recently putting some example code into the appendix of a journal paper we are writing and it occurred to me: when a person goes to run this code in 5+ years time, they will do pip install porespy=2.0.2 (the version I will mention in the paper)ā¦but because we have no hard dependencies, they will get the latest version of all our dependencies so there is no guarantee the code will work.
So then it occurred to me, it would be perfect if a user could instead to pip install porespy@2021-12-31. This would tell pip to install all the versions of the package that were present on PyPI on that date! Voila, the user would get a fully functioning, albeit very out of date, installation. Obviously they would need to do this in a clean virtualenv.
I just wanted to throw this idea out to see if itās crazy or not. I have googled this of course, but nothing unique comes up.
Also, as a side note, I am very interested in any suggestions for how to handle this using existing options. The best option I can see now is generating pre-compiled binaries and posting on github as a release.
Couldnāt you just also put the contents of a pip freeze into the appendix? Or, include the pip freeze output as a separate requirements.txt in the SI?
I have not used this before, but that would solve the immediate issue, thanks!
With my ācrazy ideaā I was thinking more generally about making repeatable installs. If pip actually added this feature, then it would probably work for any package no matter how old, right?
<nod>, I was just noting an option for your current need.
From my limited experience with the PyPI/warehouse codebase and database schema, I suspect it would be possible to implement a feature like what you describe, at least specifically for PyPI. pip interacts with more repositories than just PyPI, though, and so it may be a really challenging feature to make work in general.
Thereās also the question of the size of the the community need versus the development and maintenance burden. Iām curious to see if/how discussion continues on the topic.
Yes and no. āpip freezeā also works no matter how old.
Butā¦ if some maintainer removes a package revision (eg due to a
serious bug) then the pip freeze approach will break, making that
abundantly clear. Going by date might simply pick an earlier version
(maybe lacking a feature, or having a bug which had been fixed in the
now-removed version).
So Iād advocate the pip freeze approach regardless. Its failure is more
predictable and meaningful.
pip freeze will work great actually. I think we can get our github Actions to generate this and include it in the release notes each time we do the ādeployā action, and weāll be all set. Thanks again.
I am working on a project with a somewhat involved dependency chain. We recently had an issue where our installations were stalled due to stuckness in pip dependency resolver after one of our dependencies made a release. We have since mitigated the issue, however the feature being asked here would made it possible to easily provide a repro of the suboptimal dependency resolver behavior to pip maintainers. It could also be helpful to provide an immediate workaround to users who havenāt been following the practice of using pip freeze.
+1.
To note, if you want to make a feature request for pip, pipās issue tracker would be the place to do so. There appears to already be at least one issue that links to related ones.