On November 7, 2015 at 8:56:02 AM, Ralf Gommers (ralf.gommers@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@python.org https://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA