[Python-Dev] Accept just PEP-0426
ncoghlan at gmail.com
Tue Nov 20 16:49:28 CET 2012
On Wed, Nov 21, 2012 at 1:16 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk>wrote:
> Daniel Holth <dholth <at> gmail.com> writes:
> > If you don't have Provides-Dist, then distribute must continue to bundle
> > extra .egg-info directory to emulate the feature. This is more than
> > justification for me. Name: is essentially an alias for Provides-Dist:
> > vice-versa) so there is no such thing as a single-valued Provides-Dist.
> > two names for a package is just as complicated as having twenty.
> I'm not so sure. In the case of two names, it could be assumed that one
> was a
> fork of the other (as in the specific cases of distribute/setuptools, or
> Pillow). You cannot reasonably make this assumption if you have twenty
> in your Provides-Dist.
> > You should not implement Provides-Dist by searching for every
> > name on PyPI.
> I wasn't seriously suggesting that this approach be taken - merely
> pointing out
> that Provides-Dist isn't of much use in a metadata index.
> > should only use it when deciding whether to download setuptools when
> > is already installed and a package depends on setuptools.The bundling
> term was
> > bad wording on the part of the PEP. No one should ever include
> > copies of other dists in their dists "import six" vs. "import
> > I've suggested a new wording in this thread.
> So apart from the setuptools/distribute and PIL/Pillow scenarios, what are
> scenarios where you would have 3 or more values in Provides-Dist? If they
> e.g. a bundled SQLAlchemy, why would that be preferable to an entry in
Provides/Requires/Obsoletes are *not* for bundling. Publishing bundled
packages on the index is bad, and people shouldn't do it. What they're for
is tracking name changes over time, so that you can fork and rename and
merge projects without breaking the world for people that depend on your
projects (one example used in the Fedora RPM docs is the apache package
being renamed to httpd:
The fact distribute can provide setuptools and Pillow can provide PIL are
examples of the simple fork/rename case - they're designed to be drop in
replacements for the projects they forked, so it's appropriate for them to
advertise that fact in a way the deployment tools can understand. The
multi-value support is then needed if you have multiple name changes over
time (e.g. if someone were to create a distribute2 that provided both
distribute and setuptools), or if you merge two projects together (e.g. if
a popular extension to a project was folded into the main distribution for
It's likely fine if an installer doesn't use sophisticated graph analysis
to find the "best" way to satisfy a set of requirements - you can just as
easily use it in the simple way Daniel describes of only using these fields
to check for existing locally installed packages with the necessary
capabilities, before going out to get whatever is missing from the package
index based purely on the distribution names.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev