
<html><head></head><body>That's a straw man, this has enough inconsistency potential to break many edge cases in ugly ways,<br>

So global setup is out.<br>

Projects themselves can really just switch to pip commands, same goes for packagers and other tool makers<br>

<br>

Explicit is better than implicit, and in this case it also won't cost additional maintenance on setuptools.<br>

Please keep in mind, that setuptools is completely on volunteer time, and the time given to it is scarce.<br>

<br>

<br><br><div class="gmail_quote">Am 7. Dezember 2015 05:36:42 MEZ, schrieb Nick Coghlan <ncoghlan@gmail.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">On 4 December 2015 at 17:55, Ronny Pfannschmidt<br /><opensource@ronnypfannschmidt.de> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> But it still needs a change in command<br /> A direct switch to a real pip command comes with a free implementation and zero additional features to maintain in setuptools<br /></blockquote><br />The key point here is that opting in to this new behaviour would just<br />mean setting a new configuration flag in pydistutils.cfg on the system<br />doing the build/install, or adding a new option to the list of options<br />passed to the install command. That's a significantly lower barrier to<br />entry than finding all of the occurrences of "./<a href="http://setup.py">setup.py</a> install" in<br />existing packaging and deployment scripts and converting them over to<br />use "pip install" instead, especially since all the *other* command<br

/>line flags would continue to be the setuptools flags rather than the<br />pip ones.<br /><br />Cheers,<br />Nick.<br /></pre></blockquote></div><br>

-- <br>

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.</body></html>