On Fri, Sep 21, 2012 at 12:59 PM, Donald Stufft <donald.stu...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
