<p dir="ltr">Thanks for starting this up again!</p>
<p dir="ltr">My vote is for 1c (easier to add 1a later), and dashes (for some reason I just like how they look more in config files).</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 23, 2016, 06:36 Thomas Kluyver, <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd like to push PEP 517 forwards again. This PEP specifies a general<br class="gmail_msg">
build system interface so that a source tree can specify a tool (such as<br class="gmail_msg">
flit), and pip can ask that tool to generate a wheel. This would allow<br class="gmail_msg">
us to install from an sdist or a VCS checkout without running a setup.py<br class="gmail_msg">
file.<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://www.python.org/dev/peps/pep-0517/" rel="noreferrer" class="gmail_msg" target="_blank">https://www.python.org/dev/peps/pep-0517/</a><br class="gmail_msg">
<br class="gmail_msg">
Developments since the last time this was discussed (to my knowledge):<br class="gmail_msg">
- It now uses the pyproject.toml file specified in PEP 518, which was<br class="gmail_msg">
already accepted. 517 originally specified a JSON file; 518 explains why<br class="gmail_msg">
TOML is preferred (basically: comments).<br class="gmail_msg">
- I have implemented the proposed build-system API in a pull request for<br class="gmail_msg">
Flit; this has been fairly straightforward so far.<br class="gmail_msg">
<a href="https://github.com/takluyver/flit/pull/77" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/takluyver/flit/pull/77</a><br class="gmail_msg">
<br class="gmail_msg">
Questions:<br class="gmail_msg">
1. Editable installs. The PEP currenly specifies a hook to do an<br class="gmail_msg">
editable install (like 'pip install -e' or 'setup.py develop') into a<br class="gmail_msg">
given prefix. I don't think that specifying a prefix is sufficient to<br class="gmail_msg">
cover '--user' installation, which uses a different install scheme,<br class="gmail_msg">
especially on Windows and OSX framework builds. We can:<br class="gmail_msg">
a. Add an extra parameter 'user' to the hook, to override the prefix and<br class="gmail_msg">
do a user install.<br class="gmail_msg">
b. Leave it as is, and do not support editable user installation (which<br class="gmail_msg">
would make me sad, as I do editable user installs regularly)<br class="gmail_msg">
c. Decide that editable installs are too fiddly to standardise, and<br class="gmail_msg">
leave it to users to invoke a tool directly to do an editable install.<br class="gmail_msg">
<br class="gmail_msg">
2. Dash vs. underscore, bikeshed reloaded! Currently,  the table name<br class="gmail_msg">
uses a dash: [build-system], but the key added by PEP 517 uses an<br class="gmail_msg">
underscore: build_backend. This seems a bit messy. I propose that we<br class="gmail_msg">
change build_backend to build-backend for consistency. Dashes and<br class="gmail_msg">
underscores can both be used in a TOML key without needing quoting.<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Thomas<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" class="gmail_msg" target="_blank">Distutils-SIG@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class="gmail_msg">
</blockquote></div>