[Distutils] .egg-info metadata

[PJ Eby]

On Fri, Sep 21, 2012 at 12:24 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Sep 21, 2012 at 1:58 PM, PJ Eby <pje at telecommunity.com> wrote:
>> On Thu, Sep 20, 2012 at 10:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On Fri, Sep 21, 2012 at 12:08 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
>>>> Maybe that's just me though.
>>>
>>> Nope, it's "In the face of ambiguity, refuse the temptation to guess"
>>> applied to dependency metadata.
>>
>> How are dependency links guessing anything?
>
> What are they a link to? What OSes will it run on? How do you install
> them? As you soon as you step outside the defined dependency
> framework, it's all guesswork.

I'm not seeing how a documented file discovery protocol is
"guesswork".  Perhaps you've not read the documentation?  e.g.:

http://peak.telecommunity.com/DevCenter/setuptools#dependencies-that-aren-t-in-pypi
http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall

This is no more guesswork than the PyPI /simple index discovery protocol is.

The only part I can think of in the whole process that is actually
guesswork is interpreting distutils-generated (as opposed to
setuptools-generated) distribution filenames -- a necessary nod to
backward-compatibility.

As far as the practicality vs. purity question, Python has already had
Provides/Requires in the metadata format for several years, and it
contained all the features that were needed for a "pure" dependency
resolution system.  In *theory* you could meet everyone's use cases
with that, if you're going to assume that all packages live in PyPI
and everyone has a compiler.  And then there wouldn't be any need for
any of the new metadata specs.

In practice, however, not everything's in PyPI and not everybody has
compilers, and not every package is instantly updated or maintained
indefinitely.  If you don't like how dependency links solve the
problem, perhaps you could propose some other way of handling those
use cases, such that developer B's dependency maintenance burdens are
not propagated to developer A and his peer/parent dependers?