<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
OK, so which setup() arguments do we want to leave out of the static
metadata?<br>
<br>
<div class="moz-cite-prefix">05.05.2016, 23:53, Daniel Holth
kirjoitti:<br>
</div>
<blockquote
cite="mid:CAG8k2+7DUZ6H277_JebJwXF9xUpCvm_rijQ=0+3dggizQBm9Jw@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
href="mailto:alex.gronholm@nextday.fi"><a class="moz-txt-link-abbreviated" href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a></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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:ncoghlan@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a></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 moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>