[Distutils] .egg-info metadata

[Erik Bray]

On Fri, Sep 21, 2012 at 12:57 AM, PJ Eby <pje at telecommunity.com> wrote:
> 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

Exactly.  This is the opposite of guesswork, in fact.  I have use
cases where I want to know/specify exactly where my dependencies are
coming from, and not just put out an abstract name.  I agree this
information shouldn't be a part of the package's Metadata.  I think
the existing solution in setuptools of including it in a
dependency_links.txt file is fine.  This wouldn't be an option though
with Nick's "one JSON file to rule them all" proposal (which I'm not
against--it just precludes keeping dependency-links-like info out of
band).

> 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?

And not everybody wants to put everything on PyPI. In fact, I once had
a use case to build a system on top of pkg_resources that could locate
dependencies in SVN repository checkouts by adding their paths to
dependency_links/find_links.  There are all kinds of uses for this
kind of thing that I don't think should be ignored, and pkg_resources
has already provided the means to implement most of them (the
aforementioned example also required subclassing easy_install to work
properly, but that wasn't too big a deal).

I think a broader point is that package distribution and dependency
resolution has some ugly and messy corners and there's no way around
that.  Just saying, "Well all the dependencies should be clearly
documented and it's up to the user to figure how to assemble them all"
isn't going to fly either.

Erik