On 16 May 2015 at 11:52, Robert Collins <robe...@robertcollins.net> wrote: > On 16 May 2015 at 13:45, Donald Stufft <don...@stufft.io> wrote: >> >>> On May 15, 2015, at 9:22 PM, Robert Collins <robe...@robertcollins.net> >>> wrote: >>> >>> On 16 May 2015 at 11:08, Marcus Smith <qwc...@gmail.com> wrote: >>>> Why not start with pip at least being a "simple" fail-on-conflict resolver >>>> (vs the "1st found wins" resolver it is now)... >>>> >>>> You'd "backtrack" for the sake of re-walking when new constraints are >>>> found, >>>> but not for the purpose of solving conflicts. >>>> >>>> I know you're motivated to solve Openstack build issues, but many of the >>>> issues I've seen in the pip tracker, I think would be solved without the >>>> backtracking resolver you're trying to build. >>> >>> Well, I'm scratching the itch I have. If its too hard to get something >>> decent, sure I might back off in my goals, but I see no point aiming >>> for something less than all the other language specific packaging >>> systems out there have. >> >> >> So what makes the other language specific packaging systems different? As far >> as I know all of them have complete archives (e.g. they are like PyPI where >> they >> have a lot of versions, not like Linux Distros). What can we learn from how >> they >> solved this? > > NB; I have by no means finished low hanging heuristics and space > trimming stuff :). I have some simple things in mind and am sure I'll > end up with something 'good enough' for day to day use. The thing I'm > worried about is the long term health of the approach.
Longer term, I think it makes sense to have the notion of "active" and "obsolete" versions baked into PyPI's API and the web UI. This wouldn't be baked into the package metadata itself (unlike the proposed "Obsoleted-By" field for project renaming), but rather be a dynamic reflection of whether or not *new* users should be looking at the affected version, and whether or not it should be considered as a candidate for dependency resolution when not specifically requested. (This could also replace the current "hidden versions" feature, which only hides things from the web UI, without having any impact on the information published to automated tools through the programmatic API) Tools that list outdated packages could also be simplified a bit, as their first pass could just be to check the obsolescence markers on installed packages, with the second pass being to check for newer versions of those packages. While the bare minimum would be to let project mantainers set the obsolescence flag directly, we could also potentially offer projects some automated obsolescence schemes, such as: * single active released version, anything older is marked as obsolete whenever a new (non pre-release) version is uploaded * semantic versioning, with a given maximum number of active released X versions (e.g. 2), but only the most recent (according to PEP 440) released version with a given X.* is active, everything else is obsolete * CPython-style and date-based versioning, with a given maximum number of active released X.Y versions (e.g. 2), but only the most recent (according to PEP 440) released version with a given X.Y.* is active, everything else is obsolete Pre-release versions could also be automatically flagged as obsolete by PyPI as soon as a newer version for the same release (including the final release itself) was uploaded for the given package. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
