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. Back in the day I struggle mightily with kludging sys.path, and, relative imports that never really worked right, and on and on -- it SUCKED. Then I discovered setuptools develop mode -- yeah! IN fact, I don't think I'd ever use setuptools at all if I didn't need it to get develop mode! c. Decide that editable installs are too fiddly to standardise, and > leave it to users to invoke a tool directly to do an editable install. > Not sure what that means -- does that mean that you couldn't get an editable isntall with pip? but rather you would do: setup.py develop if you had setuptools as your build system, and some_other_command if you had some other build tool? Not too bad, but why not have a standard way to invoke develop mode? If the tool can support it, why not have a way for pip to tell an arbitrary build system to "please install this package in develop mode" On the other hand: I've always thought we were moving toward proper separation of concerns, in which case, pip should be focused on resolving dependencies and finding and installing packages. Should it even be possible to build and install a package from source with pip? But if it is, then it might as well support editable installs as well. The complication I see here is that a tool can't know how to install in editable mode unless it knows about the python environment it it running in -- which is easy for a tool built with python, but a problem for a tool written some other way. However, I see from PEP 517: The build backend object is expected to have attributes which provide some or all of the following hooks. The commonconfig_settings argument is described after the individual hooks: def get_build_requires(config_settings): ... So I guess we can count on a Python front end, at least, so 1(a) should be doable. In fact, is the user-install issue any different for editable installs than regular ones? -CHB > 2. Dash vs. underscore, bikeshed reloaded! Currently, the table name > uses a dash: [build-system], but the key added by PEP 517 uses an > underscore: build_backend. This seems a bit messy. I propose that we > change build_backend to build-backend for consistency. Dashes and > underscores can both be used in a TOML key without needing quoting. > > Thanks, > Thomas > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig