On Tue, 27 Oct 2015 at 02:17 Robert Collins <robe...@robertcollins.net> wrote:
> On 27 October 2015 at 21:47, David Cournapeau <courn...@gmail.com> wrote: > > > Another simple solution for this particular case is to add conflict rules > > between packages that provide the same requirement (that's what php's > > composer do IIRC). > > > > The case of safety against malicious forks is handled quite explicitly in > > composer, we may want to look at how they do it when considering > solutions > > (e.g. https://github.com/composer/composer/issues/2690, though it has > > changed a bit since then) > > > > Adding the provides/conflict concepts to pip resolver will complexify it > > quite significantly, both in terms of running time complexity (since at > that > > point you are solving a NP-complete problem) and in terms of > implementation. > > But we also know for real cases this is doable, even in pure python > > (composer handles all the cases you are mentioning, and is in pure php). > > We already require a full NP-complete solver because of <, <= and ~ > version operators. > > I haven't adsorbed this proposal enough to comment on the reification > aspect yet. > > I'm worried about provides and conflicts in general, but not from a > resolver code perspective - thats a one-ish-time-cost, but instead > from a user experience perspective. > So from my perspective as someone who (I think) grasps what the problems that everyone is trying to solve is but not knowing enough to know how stuff is done now (all my projects on PyPI are pure Python), Nathaniel's proposal makes total sense to me. I would think it would be easy to explain to a scientist that "to get scipy, run `python3.5 -m pip install numpy`, but if you want fast over open source and use Intel's MKL library, do `python3.5 -m pip install numpy[mkl]`. I think the syntax clearly shows it's a modification/tweak/special version of numpy and it makes sense that I want to install something that provides numpy while relying on MKL. Nathaniel's comment about how this might actually give pip a leg up on conda also sounds nice to me as I have enough worry about having a fissure in 1D along the Python 2/3 line, and I'm constantly worried that the scientific community is going to riot and make it a 2D fissure along Python 2/3, pip/conda axes and split effort, documentation, etc.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
