On Fri, Sep 21, 2012 at 12:24 AM, Nick Coghlan <[email protected]> wrote: > On Fri, Sep 21, 2012 at 1:58 PM, PJ Eby <[email protected]> wrote: >> On Thu, Sep 20, 2012 at 10:51 PM, Nick Coghlan <[email protected]> wrote: >>> On Fri, Sep 21, 2012 at 12:08 PM, Donald Stufft <[email protected]> >>> wrote: >>>> Maybe that's just me though. >>> >>> Nope, it's "In the face of ambiguity, refuse the temptation to guess" >>> applied to dependency metadata. >> >> How are dependency links guessing anything? > > What are they a link to? What OSes will it run on? How do you install > them? As you soon as you step outside the defined dependency > framework, it's all guesswork.
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 This is no more guesswork than the PyPI /simple index discovery protocol is. The only part I can think of in the whole process that is actually guesswork is interpreting distutils-generated (as opposed to setuptools-generated) distribution filenames -- a necessary nod to backward-compatibility. 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? _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
