C extensions, py-modules, ... On Thu, May 5, 2016, 17:05 Alex Grönholm <alex.gronh...@nextday.fi> wrote:
> 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> > 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> 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 >> >> >> >> _______________________________________________ >> Distutils-SIG maillist - >> Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig >> >> _______________________________________________ >> Distutils-SIG maillist - 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
