<div dir="ltr">This is a recurring point of confusion. <span style="line-height:1.5">setup.py is not ever going away. In general it is necessary for you to be able to write software to build your software, and there is no intention to take that feature away.</span><div><br></div><div><div>People repeatedly come to the conclusion that static metadata means the entire build is static. It's only the dependencies that need to be static to enable better dependency resolution in pip. The build does not need to be static.</div><div><br></div><div><span style="font-family:'helvetica neue',helvetica,arial,sans-serif;line-height:1.5">The proposed feature means you will be able to have a simpler setup.py or no setup.py it by using something like flit or pbr that are configured with .cfg or .ini. setup.py is not going away.</span></div></div><div><span style="font-family:'helvetica neue',helvetica,arial,sans-serif;line-height:1.5"><br></span></div><div><span style="font-family:'helvetica neue',helvetica,arial,sans-serif;line-height:1.5">Static metadata means the list of dependencies, author name, trove classifiers is static. Not the build itself.</span></div><div><span style="font-family:'helvetica neue',helvetica,arial,sans-serif;line-height:1.5"><br></span></div><div><span style="font-family:'helvetica neue',helvetica,arial,sans-serif;line-height:1.5">Enforced staticness of the build script is right out.</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 5, 2016 at 4:34 PM Alex Grönholm <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    I think it would be best to gather a few extreme examples of
    setup.py files from real world projects and figure out if they can
    be implemented in a declarative fashion. That at least would help us
    identify the pain points.<br>
    <br>
    For starters, gevent's setup.py looks like it needs a fair bit of
    custom logic:<br>
    <a href="https://github.com/gevent/gevent/blob/master/setup.py" target="_blank">https://github.com/gevent/gevent/blob/master/setup.py</a><br>
    <br>
    <div>05.05.2016, 23:30, Chris Barker
      kirjoitti:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Wed, May 4, 2016 at 7:45 PM, Nick
            Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>
            wrote:<br>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This
              configuration vs customisation distinction is probably
              worth<br>
              spelling out for folks without a formal software
              engineering or<br>
              computer science background, so:<br>
            </blockquote>
            <div><br>
            </div>
            <div>fair enough -- good to be clear on the terms.</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              Configuration is different: you're choosing amongst a set
              of<br>
              possibilities that have been constrained in some way, and
              those<br>
              constraints are structurally enforced. </blockquote>
            <div><br>
            </div>
            <div>That's a key point here -- I guess I'm skeptical that
              we can have the flexibility we need with a purely
              configuration-based system -- we probably don't WANT to
              constrain the options completely. If you think about it,
              while distutils has it's many, many flaws, what made it
              possible for it to be as useful as it is, and last as long
              as it has because is CAN be customized -- users are NOT
              constrained to the built-in functionality.</div>
            <div><br>
            </div>
            <div>I suspect the idea of this thread is to keep the API to
              a build system constrained -- and let the build systems
              themselves be as customizable as the want to be. And I
              haven't thought it out carefully, but I have a feeling
              that we're going to hit a wall that way .. but maybe not.</div>
            <div> <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Usually
              that enforcement is<br>
              handled by making the configuration declarative - it's in
              some passive<br>
              format like an ini file or JSON, and if it gets too
              repetitive then<br>
              you introduce a config generator, rather than making the
              format itself<br>
              more sophisticated.<br>
            </blockquote>
            <div><br>
            </div>
            <div>OK -- that's more or less my thought -- if it's  python
              that gets run, then you've got your config generator built
              in -- why not?</div>
            <div><br>
            </div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              The big advantage of configuration over customisation is
              that you<br>
              substantially increase the degrees of freedom in how
              *consumers* of<br>
              that configuration are implemented - no longer do you need
              a full<br>
              Python runtime (or whatever), you just need an ini file
              parser, or a<br>
              JSON decoder, and then you can look at just the bits you
              care about<br>
              for your particular use case and ignore the rest.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Sure -- but do we care? this is about python packaging
              -- is it too big a burden to say you need python to read
              the configuration?</div>
            <div><br>
            </div>
            <div>-CHB</div>
            <div><br>
            </div>
          </div>
          -- <br>
          <div><br>
            Christopher Barker, Ph.D.<br>
            Oceanographer<br>
            <br>
            Emergency Response Division<br>
            NOAA/NOS/OR&R            (206) 526-6959   voice<br>
            7600 Sand Point Way NE   (206) 526-6329   fax<br>
            Seattle, WA  98115       (206) 526-6317   main reception<br>
            <br>
            <a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
        </div>
      </div></blockquote></div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a>
</pre>
    </blockquote></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>