On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver <tho...@kluyver.me.uk> > wrote: > >> >> Questions: >> 1. Editable installs. The PEP currenly specifies a hook to do an >> editable install (like 'pip install -e' or 'setup.py develop') into a >> given prefix. I don't think that specifying a prefix is sufficient to >> cover '--user' installation, which uses a different install scheme, >> especially on Windows and OSX framework builds. We can: >> a. Add an extra parameter 'user' to the hook, to override the prefix and >> do a user install. >> b. Leave it as is, and do not support editable user installation (which >> would make me sad, as I do editable user installs regularly) > > > Please, please, let's figure SOMETHING our here - editable installs (or > "develop" installs) are a critical tool. Frankly, I don't know how anyone > can develop a package without them.
Would a 'pip watch' command that watched your source tree and rebuilt/reinstalled it whenever you edited a file work for you? What do you do for conda packages? Does conda have an editable install equivalent? The problem with editable installs is that they can't really be made to work "properly", in the sense of having solid invariants and fitting nicely into a rigorously defined metadata model -- they're always going to have weird footguns around the metadata / .py files / .so files getting out-of-sync with each other, and they make it harder to improve pip's infrastructure around upgrading, because upgrading requires pip to have a solid understanding of exactly what's installed. So it's absolutely possible to have some useful hack, like we do now, but useful hacks by their nature are hard to standardize: standardization means "this is the final solution to this problem, it won't need further tweaking", and editable installs really feel like they might benefit from further tweaking. Or something. Also note that just like we decided to split the basic pyproject.toml proposal (now PEP 518) from the build system interface proposal (now PEP 517), it might (probably) makes sense to split the editable install part of the build system interface proposal from the rest, just in the interests of making incremental progress. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
