Only return python packages from the first available index from which they can be found.

#139 Declined
  1. Daniel Haskin

Say I have package 'a' on index 'x' which lists index 'y' as a base index. That is, 'x' inherits from 'y'. A common use case is to want to install package 'a' from 'x' and 'y'. If I wanted the version of 'a' listed on in the 'y' index, I would have listed that index in my pip configuration. But I want the version of 'a' listed in index 'x', not 'y'.

Currently, if I as a user point pip to index 'x', pip will only install 'a' from 'x' if the package 'a' is of a later version than the package 'a' listed in 'y'. But in our scenario, pip should always install the package 'a' listed in index 'x', not 'y', else there would be no need for multiple repositories at all.

This patch fixes that. With this patch, if devpi is queried for a package 'a' from index 'x', it will get package 'a' from 'x' every time, even if a newer version of 'a' is listed in index 'y'.

Comments (4)

  1. Stephan Erb

    At the moment, my team is heavily relying on the fact that an index does not shadow packages from its bases. Is there a reason why you don't like it? I mean, if you want a specific version you have to pin it anyway.

  2. Daniel Haskin author

    We use git flow at our office.

    Say we branch from the develop branch of a whose version is 0.0.0.dev38, where 38 is the build number of how many times we've built off the develop branch. We place the built package for a in a develop index which corresponds to the develop branch. Then we branch from develop in our git repository to create a new feature. We would like to test our work on that featur,e so we make an index on devpi for the feature branch that inherits from the develop index. That way testers get the feature version of packages that need testing and the develop version of packages they just need as dependencies. We may even branch from develop in a different python repository with the same feature branch name so that both repos have their python packages on the same feature index.

    However, since it's a new feature, the build number of a is likely 1, and so the version on the feature index becomes 0.0.0.dev1 . Under the current rules, even if I point my testers at the feature index, they don't know which version of the package they're getting. If the develop version is higher, they get that one, and if the feature version is higher, they get the feature pip package. In order to guarantee that the feature branch package of a was the one we got, we had to patch devpi. The patch we used was submitted as this pull request.

    I think this is a common enough use case to at least warrant a configuration file or commandline option. What do you think of making this an option to devpi, something that can be enabled or disabled? Perhaps we could make it an option when an index is created, whether or not that index is a "shadow" index or not.

    If we want to do this, would you like me to create an issue? I would be happy to contribute code to it, subject to your review.

    1. Matt Allen

      As a global setting, this is probably not a great thing. As a per-index setting, this would be really handy in situations like @djhaskin987 is describing.

  3. Holger Krekel repo owner

    Several things i'd like to comment but actually we should rather discuss the work flow and how to map it with devpi on the ML. Could you respost on the mailing list?