[Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

Donald Stufft donald at stufft.io
Sat Nov 7 09:49:55 EST 2015

On November 7, 2015 at 8:56:02 AM, Ralf Gommers (ralf.gommers at gmail.com) wrote:
> On Sat, Nov 7, 2015 at 2:02 PM, Paul Moore wrote:
> > On 7 November 2015 at 01:26, Chris Barker - NOAA Federal
> > wrote:
> > > So what IS supposed to be used in the development workflow? The new
> > > mythical build system?
> >
> I'd like to point out again that this is not just about development
> workflow. This is just as much about simply *installing* from a local git
> repo, or downloaded sources/sdist.
> The "pip install . should reinstall" discussion in
> https://github.com/pypa/pip/issues/536 is also pretty much the same
> argument.

I think that everyone on that ticket has agreed that ``pip install .`` (where . is any local path) should reinstall. I think the thing that is being asked for here though is for pip to use that directory as the build directory, rather than copying everything to a temporary directory and using that. I’m hesitant to do that because it’s going to add another slightly different way that things could be installed and I’m trying to reduce those (and instead have two “paths” for installation, the normal one and the development one).

IOW, I think in development ``-e`` is the right answer if you want to build and use the local directory. Otherwise you shouldn’t expect it to modify your current directory or the tarball at all. I do think we can make sure that specifying a build directory and instructing us not to clean it will function to have incremental builds though.

> Fair question. Unfortunately, the answer is honestly that there's no
> > simple answer - pip is not a bad option, but it's not its core use
> > case so there are some rough edges.
> My impression is that right now pip's core use-case is not "installing",
> but "installing from PyPi (and similar repos". There are a lot of rough
> edges around installing from anything on your own hard drive.

This is probably true just in the fact that the bulk of the time when people use it, they are using it to install from a remote repository. There are rough edges for stuff on your own hard drive, but I think we can clean them up though, we just need to figure out what the answer is for each of those rough cases.

> > I'd argue that the best way to use
> > pip is with pip install -e, but others in this thread have said that
> > doesn't suit their workflow, which is fine. I don't know of any other
> > really good options, though.
> >
> > I think it would be good to see if we can ensure pip is useful for
> > this use case as well, all I was pointing out was that people
> > shouldn't assume that it "should" work right now, and that changing it
> > to work might involve some trade-offs that we don't want to make, if
> > it compromises the core functionality of installing packages.
> >
> It might be helpful to describe the actual trade-offs then, because as far
> as I can tell no one has actually described how this would either hurt
> another use-case or make pip internals much more complicated.
> Ralf
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

More information about the Distutils-SIG mailing list