<div dir="ltr">We're not just grumpy, we have seen The One Build System idea tried several times with bad results. Instead, if you have the inclination, time, and ability, you could try to build a new competing build system like <a href="http://flit.readthedocs.org/">http://flit.readthedocs.org/</a> did, or you could help try to figure out how to improve support for said competing build systems in pip, or you could even try to make a pip replacement that is better for distributing end-user applications. Ideally one of these new build systems will be compelling enough that new packages will choose to use it instead of distutils in the same way that people choose Django over the cgi module.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 21, 2015 at 2:08 PM Wayne Werner <<a href="mailto:waynejwerner@gmail.com">waynejwerner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 12:32 PM, David Cournapeau <span dir="ltr"><<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>></span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Oct 21, 2015 at 6:03 PM, Ronny Pfannschmidt <span dir="ltr"><<a href="mailto:opensource@ronnypfannschmidt.de" target="_blank">opensource@ronnypfannschmidt.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
why does that have to be in setuptools ?!<br>
<br>
if we want a new light system to begin with, shouldn't it be far
more sustainable to use just implementations of the new standards
rather than leaving all of setuptools<br>
<br>
there is no viable way in setuptools to get rid of the legacy ina
sane and fast manner, it would drag out over years<br></div></blockquote><div><br></div></span><div>agreed. I have never met a person who had to deal substantially with distutils code and enjoyed the experience.<br><br></div><div>The whole architecture is fundamentally flawed. I wrote this a long time ago, but I still stand by most arguments: <a href="https://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution/" target="_blank">https://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution/</a></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I've (luckily?) never had to deal with distutils code... I am definitely digging the post. First time I've read it, but I am definitely more pro-standard-interface-and-let-tools-do-with-it-what-they-will than I was a few minutes ago.</div><div><br></div><div>Would pip's freeze format work a la the cabal file, or is it missing too much information?</div><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>-Wayne </div></div></div></div>
_______________________________________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div>