[Distutils] .egg-info metadata

[Donald Stufft]

On Friday, September 21, 2012 at 11:14 AM, PJ Eby wrote:
> Yes, but that was still sufficient information to implement a
> dependency system, in theory. Specifically, it would have worked for
> the case where all projects are on PyPI and have correct metadata.
> 
> If you assume that condition, you can trivially solve all
> dependencies; but if you don't assume that condition, you need
> something like dependency links.
> 
> 

How would you take ``requires: tastypie`` and turn it into `django-tastypie`? Remebering
that PyPI enforces a unique distribution name, not a unique python package (in the import
sense) name. In tastypie's case there are 2 libraries that both provide a top level ``tastypie``
import, one is on PyPI as just ``tastypie`` and the other is ``django-tastypie``.

That also sidesteps the issue that those fields were already in use and if they were
hijacked for this new purpose all that old data would (could?) have created issues. The
new meta-data sidestepped all these issues.
> For the same reason that requiring someone to read the source code of
> every function called by every function called by every function
> called by code they use isn't an ok thing to do.

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 is indeed wrong. Dependency links are a last resort, used after
> all other provided dependency resolution sources have failed.

This makes them better than I thought, but still have the "installability" and
security. 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? 
> That's what --allow-hosts is for: easy_install can be locked down to
> not install except from your local intranet or PyPI or whatever, and
> it can be done on a sitewide basis by default (by settings in the
> site's distutils.cfg).

I'd have been less uneasy about them if they were opt in instead of 
opt out, but that'd require a time machine. I'm mostly trying to stress
why I'm against them to make sure we don't repeat (in my opinion)
the mistakes of the past.

I should probably mention here that I don't particularly blame setuptools
for their invention, I think it's a side effect of one tool owning the entire
packaging chain from top to bottom and not any fault with the implementer(s)
and because easy_install (to my knowledge) does not have anything like
a requirements file from pip so without that the obvious place for these
"extra locations" is a setup.py. I just think it's better to split them out and
keep the packaging metadata abstract, and them have the concrete meta-data
be inferred by taking that abstract data and combining it with a requirements.txt
like file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120921/b758fc58/attachment.html>