[Distutils] .egg-info metadata

[PJ Eby]

On Fri, Sep 21, 2012 at 12:59 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
> How would you take ``requires: tastypie`` and turn it into
> `django-tastypie`?

By matching Requires with Provides at the index level.  That is, by
having PyPI index packages' Provides so that you can search for
packages that match a given Requires.

> As I said before, obviously you must draw the line somewhere. setuptools
> choose to draw it at a different place than I believe it should have. I
> don't
> believe saying "you must be using some combination of indexes that
> include all the dependencies or else you'll need to manually fetch them" is
> that large of a burden or requirement to make, obviously you disagree.

This wasn't added because I personally disagreed, it's the managers of
projects that use large dependency sets while also being relied upon
as part of other projects' large dependency sets.


> This makes them better than I thought, but still have the "installability"
> and
> security.

How is this any different than any other part of PyPI?

> The question this raises in my head, can they be used for any
> dependency, or only dependencies that the distribution defining them has?
> e.g. if I install Foo, and it depends on Bar, and Wat, and Bar has a
> dependency_links, will it only work for Bar and it's dependencies
> or will it work for Wat's dependencies as well?

I would have to dig into the code to be sure, actually.  But I don't
see any problem with restricting them to the dependency subtree being
resolved.  It's possible that the current easy_install implementation
leaks dependencies to sibling installs, but if it does, it's probably
not hard to fix.

> and because easy_install (to my knowledge) does not have anything like
> a requirements file from pip

I just googled requirements.txt, so now I understand why people are so
confused about dependency_links.  Dependency links are *not*
requirements.txt.  A pip requirements.txt is basically equivalent to a
set of easy_install command line options.

So, technically, you can do something  "easy_install `cat
requirements.txt`" and use a requirements.txt with it.  ;-)

Dependency links, OTOH, are only parameters to the easy_install
--find-links option: a *much* more limited functionality.  Not only is
it not the same functionality, the *use case* is quite different as
well.  Requirements.txt is for people installing packages, dependency
links are for people *providing* packages.  Shipping it in-band is the
whole point of the operation.


> so without that the obvious place for these
> "extra locations" is a setup.py.

Again: the entire point of dependency_links is to have an in-band,
automated way to ship third-party indexing information that would
otherwise require manual, out-of-band, *recursive* distribution.
Dependency links are download locations, and are independent of
version specifications.


> I just think it's better to split them out

They *are* split out - that's why they're not in requires.txt or PKG-INFO

> and keep the packaging metadata abstract, and them have the concrete meta-data

I agree that dependency links should not be part of the PKG-INFO
format.  They are indeed a concrete, practical matter for installation
tools.


> be inferred by taking that abstract data and combining it with a requirements.txt like file.

That is basically how dependency links work now, *except* that they
are not as powerful as a requirements.txt file, and they are shipped
with the distribution.

As with entry points, though, there's no need for it to be in
PKG-INFO, since it is for the convenience of installation tools and
end users; it isn't really about the project itself.