[Distutils] wacky idea about reifying extras

[Nathaniel Smith]

On Wed, Oct 28, 2015 at 5:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 29 Oct 2015 00:31, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>>
>>
>>
>> On Tue, Oct 27, 2015 at 5:45 PM, Brett Cannon <brett at python.org> wrote:
>>>
>>>
>>> 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.
>>
>> If it helps you sleep: I'm confident that no one is planning this
>> particular riot. It takes little work to support pip and conda - the hard
>> issues are mostly with building, not installing.
>
> Last time I checked "pip in a conda env" was also pretty well behaved, so
> conda seems to be settling in fairly well to being a per-user cross platform
> alternative to apt, yum/dnf, homebrew, nix, etc, rather than tackling the
> same Python specific niche as pip & virtualenv.

I'm not confident I understand all the details of how conda works
these days, but AFAIK using pip in a conda env is pretty much the
equivalent of using 'sudo pip' in RH/Fedora, i.e. it will happily
stomp all over the same files that the package manager thinks it is
managing, and probably you will get away with it (until you don't). I
could be wrong, though.

>> Smaller riots like breaking ``python setup.py install``  recommending
>> ``pip install .`` instead[1] are in the cards though:)
>
> Given the PyPA panel at PyCon US a few years ago ended up being subtitled
> "'./setup.py install' must die", I'd be surprised if that provoked a riot. I
> guess even if it does, you'll have plenty of folks prepared to help with
> crowd control :)

I think the biggest pushback so far is from Debian, b/c Debian has
standard distro-wide build scripts for python packages that have
'setup.py install' baked in, and there is perhaps some political
delicacy to convincing them they should have 'pip install' baked in
instead. In the short run I'm guessing we'll end up placating them by
giving them an override envvar that lets them keep using setup.py
install, but in the longer run this might be a good place to consider
directing some crowd control / persuasion.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org