OK, so which setup() arguments do we want to leave out of the static
metadata?
05.05.2016, 23:53, Daniel Holth kirjoitti:
This is a recurring point of confusion. 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.
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.
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.
Static metadata means the list of dependencies, author name, trove
classifiers is static. Not the build itself.
Enforced staticness of the build script is right out.
On Thu, May 5, 2016 at 4:34 PM Alex Grönholm <alex.gronh...@nextday.fi
<mailto:alex.gronh...@nextday.fi>> wrote:
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.
For starters, gevent's setup.py looks like it needs a fair bit of
custom logic:
https://github.com/gevent/gevent/blob/master/setup.py
05.05.2016, 23:30, Chris Barker kirjoitti:
On Wed, May 4, 2016 at 7:45 PM, Nick Coghlan <ncogh...@gmail.com
<mailto:ncogh...@gmail.com>> wrote:
This configuration vs customisation distinction is probably worth
spelling out for folks without a formal software engineering or
computer science background, so:
fair enough -- good to be clear on the terms.
Configuration is different: you're choosing amongst a set of
possibilities that have been constrained in some way, and those
constraints are structurally enforced.
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.
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.
Usually that enforcement is
handled by making the configuration declarative - it's in
some passive
format like an ini file or JSON, and if it gets too
repetitive then
you introduce a config generator, rather than making the
format itself
more sophisticated.
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?
The big advantage of configuration over customisation is that you
substantially increase the degrees of freedom in how
*consumers* of
that configuration are implemented - no longer do you need a full
Python runtime (or whatever), you just need an ini file
parser, or a
JSON decoder, and then you can look at just the bits you care
about
for your particular use case and ignore the rest.
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?
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>
_______________________________________________
Distutils-SIG maillist -Distutils-SIG@python.org
<mailto:Distutils-SIG@python.org>
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
<mailto:Distutils-SIG@python.org>
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
