On Mon, Dec 14, 2009 at 6:26 PM, Jorge Vargas <[email protected]> wrote: > On Thu, Dec 10, 2009 at 3:58 PM, Darren Dale <[email protected]> wrote: >> On Thu, Dec 10, 2009 at 2:30 PM, Ian Bicking <[email protected]> wrote: >>> On Thu, Dec 10, 2009 at 11:18 AM, Darren Dale <[email protected]> wrote: > >>> There isn't really; extras would be nice, but there hasn't been much >>> demand for them. pip requirement files serve a similar purpose though >>> in a somewhat different way. >> >> I brought this up on the virtualenv mailing list once before. >> Requirements files serve a very different use-case. If I want to >> define a project extra like foo[traits_qt4] that depends on a project >> with an extra like traits[qt4] > 3.2.0, I can't just list traits[qt4] >>> 3.2.0 in my requirements file, because pip is not designed to >> recursively check the (arbitrarily-named) requirements files of the >> dependencies I declare in my own requirements file. I have to keep >> track of not only my projects dependencies, but my dependencies >> dependencies, and on and on. >> > I think the problem with extras is that the concept itself is flawed. > python lacks this optional dependecies paradigm and we end up with a > bunch of hacks to get the optional dependencies to work. And in the > end you get to maintain code that checks at runtime which "option" to > choose making the extras stuff redundant at best. I can't really think > of a case where > pip install lib backend1 > pip install lib backend2 > > can't replace > > pip install lib[backend1] > pip install lib[backend2]
Maybe. I like what Enthought has done with extras. > as for requirements being a replacement what's wrong with having > several files? Lack of recursive dependency checking. What if a new version of my dependency is released, the old one is no longer available, and the new version has a new dependency? My requirements file won't install that dependency. > sure it's a little duplication (and it may get > exponential if you depend on a package that depends on other optional > dependencies) but seriously which % of package suffer from that? > > IMO extras was a misfeature that should be slowly deprecated. This is why I think talk of deprecating easy_install is premature. I value project extras, I know of other projects that value them as well. I value the ability to declare my projects' immediate dependencies and have those dependencies manage their own dependencies as well. Maybe these details should be worked out, and pip can demonstrate that it meets the needs of the community in practice before planning to deprecate easy_install. Darren _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
