Should pip support extras? Was: [venv] question about future pip capabilities
On Thu, Dec 10, 2009 at 3:58 PM, Darren Dale <dsdale24@gmail.com> wrote:
On Thu, Dec 10, 2009 at 2:30 PM, Ian Bicking <ianb@colorstudy.com> wrote:
On Thu, Dec 10, 2009 at 11:18 AM, Darren Dale <dsdale24@gmail.com> 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.
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
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] 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] as for requirements being a replacement what's wrong with having several files? 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.
Regards, Darren _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Mon, Dec 14, 2009 at 6:26 PM, Jorge Vargas <jorge.vargas@gmail.com> wrote:
On Thu, Dec 10, 2009 at 3:58 PM, Darren Dale <dsdale24@gmail.com> wrote:
On Thu, Dec 10, 2009 at 2:30 PM, Ian Bicking <ianb@colorstudy.com> wrote:
On Thu, Dec 10, 2009 at 11:18 AM, Darren Dale <dsdale24@gmail.com> 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.
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
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] 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
participants (2)
-
Darren Dale -
Jorge Vargas