On Fri, Sep 21, 2012 at 12:57 AM, PJ Eby <p...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig