<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 6:44 PM, Wayne Werner <span dir="ltr"><<a href="mailto:waynejwerner@gmail.com" target="_blank">waynejwerner@gmail.com</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 dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></div></blockquote><div><br></div><div>the main cabal file is its own DSL that describes the package metadata (so more a replacement of setup.py).<br><br></div><div>I used a similar idea when I wrote bento (<a href="https://cournape.github.io/Bento/">https://cournape.github.io/Bento/</a>), which ended up being a mistake. If I were to write a similar tool today, I would just use templated yaml. A big difference compared to 6-7 years ago is the progress made on pip, wheels, etc... A lot of the current efforts in python package (metadata formalization, etc...) are about enabling tools like bento, flit, etc... to coexist:  as long as they produced wheels/(wheel)sdist/etc... that pip can consume, you have a clear separate of concern, and an healthy competition.<br><br></div><div>David <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888"><div><br></div><div>-Wayne </div></font></span></div></div></div>
</blockquote></div><br></div></div>