Daniel Holth <dholth <at> gmail.com> writes:

> Mostly it seems a bit silly to have so much conversations about parts of the
> pep that remain unchanged from previously accepted versions...

I don't agree with the suggestion that we shouldn't discuss it because it was
accepted in a previous version. Perhaps it didn't receive the right scrutiny at
that time, but since it hasn't been implemented, it's reasonable to discuss it.

ISTM that implementing it as suggested in the PEP can lead to certain problems,
since it is a multi-valued field. If it is left in, then something should be
said in the PEP about the potential difficulties and if/how they can be
resolved.

The difficulties I am talking about relate to dependency resolution. Given the
current definition of Provides-Dist, it is possible for a package A on PyPI to
"Provide" all of e.g. "A (1.0)", "B (1.2)" and "C (1.5)", and it is also
possible for packages B and C on PyPI to provide the same (or slightly
different) versions of logical packages of A, B, and C. This will likely lead
to the need for a sophisticated dependency resolver because the dependency
graph can get quite convoluted. (Remember, we might need to do this resolution
when removing packages as well as when installing them.) I know there are SAT
solvers and such, but I'm not sure we need that level of sophistication, or
whether its complexity cost is outweighed by any benefit. Remember, we are
managing fine without multi-valued Provides-Dist, and while a case has been
made for virtual packages and forks (which just require a single-valued field),
no compelling case has been made for bundling packages in general (I understand
that such requirements might sometimes arise in certain corporate environments,
but they don't seem to be a mainstream use case). Hence, no strong case has
been made for a multi-valued "Provides" field.

If we have a good index and packaging infrastructure, there is no general need
for packages to bundle other packages, unless those bundled packages are changed
in some way to suit the bundler's needs. In that case, I don't know how you
could be sure that a bundled "A (1.0)" hasn't diverged from the equivalent
package on PyPI.

The "Provides" seems essentially useless in a metadata index, since if, when
asked to install D which has a dependency on A, you would download and install
A to resolve it rather than B or C, and I can't see when you would want to
query the index to say "who provides A?" and then use some heuristic to pick
e.g. B or C, rather than A.

distlib currently contains support for the multi-valued "Provides", but I'm
not confident that will work as expected given pathological cases like the
example I suggested, without getting "complicated" in the Zen of Python sense.
I'm not convinced that the maintenance burden of a complicated solution is
worth the heretofore unnecessary ability to bundle stuff in arbitrary ways.