Thinking about it further, I agree, Holger. Priorities only  make sense in situations where you stop at the first available found NAME. This is what happens with apt and YUM. They look for a package in the first available "index", and stop looking in other indexes once they've found it. Devpi simply doesn't work that way.

The whitelist option you have described would create the desired effect.  To that idea I would only add a special value, say "None", as in


So that the shadowing behavior can be turned off completely.

Daniel Jay Haskin

On Mon, Oct 13, 2014 at 9:50 AM, holger krekel <> wrote:
On Sat, Oct 11, 2014 at 03:49 -0700, Jürgen Hermann wrote:
> APT handles this by priorities (000 to 999), an implementation based on
> prios is not hard, more flexible, and IMHO more understandable than
> "shadowing" (i.e. in the end, a binary prio 0/1).
> Why is implementation (likely) easy? Just use the prio as an epoch to the
> version, i.e. prepend it to the versions. All other processing stays the
> same. Default prio would be 500, and prios would be an index attribute.

I am not worried about the implementation but rather about semantics.
And i am not sure how exactly to relate the apt "priorities" concept to
devpi. (I just read up on it at at bit).
Juergen, could you detail your thoughts a bit?  Below i offer mine.

Basically if we query links for a given NAME on an index INDEX,
if INDEX has release files for NAME we may either want

- to not consider base indexes of INDEX for NAME  or to

- merge release files for NAME from base indexes

This might even be a per-NAME choice not a global one for an index.
So i'd map it with an option, maybe:


so that by default we have the current behaviour but if you set

    devpi index bases_whitelist=NAME1

it would mean that only NAME1 would be merged with bases unconditionally
whereas all other names would be not be merged from bases if INDEX contains
it already.  If the INDEX does not contain a name it would be looked up
in the bases just as now.  (This is recursive definition so the base
indexes might have the same setting).

Do these considerations make sense to you? I chose bases_whitelist as an
option name because we already have pypi_whitelist.  Maybe there is some
clever more generalized option that we could do instead of having two,
not sure.  Something like:

    bases_whitelist= root/pypi=,other/base=NAME1

or so. (please don't use "," in index names btw :)


You received this message because you are subscribed to the Google Groups "devpi-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit