Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-09 Thread Chris Barker 
On Sun, May 8, 2016 at 5:49 AM, Nick Coghlan  wrote:

> The reason I think "bootstrap" is a better name at this point


I *really* don't want to add to the bike-shedding of the name at this point
-- I really don't care.

I was just trying to see if I was misunderstanding something, as it didn't
seem to be bootstrapping anything to me, and I see I was kinda missing some
of the scope and complexity -- thanks.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-09 Thread Brett Cannon 
On Mon, 9 May 2016 at 06:42 Nick Coghlan  wrote:

> On 7 May 2016 at 08:21, Paul Moore  wrote:
> > On 6 May 2016 at 19:14, Brett Cannon  wrote:
> >> OK, assuming the Nick will be pronouncing, who wants to write the PEP?
> >
> > ... and if Nick doesn't want to pronounce, I'm willing to offer to be
> > BDFL for this one. But a PEP is the first thing. (And IMO the key
> > point of the PEP is to be very clear on what is in scope and what
> > isn't - the discussions have covered a *lot* of ground and being clear
> > on what's excluded will be at least as important as stating what's in
> > scope).
>
> Answering this specifically: I'm happy to be the arbiter-of-consensus
> for this one, as my schedule's pretty clear right now (at least until
> I head to PyCon US on the 27th).
>

OK, I'll list Nick as the BDFL Delegate in the PEP then. Hoping to have a
draft to send to the list today or tomorrow.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-09 Thread Nick Coghlan 
On 7 May 2016 at 08:21, Paul Moore  wrote:
> On 6 May 2016 at 19:14, Brett Cannon  wrote:
>> OK, assuming the Nick will be pronouncing, who wants to write the PEP?
>
> ... and if Nick doesn't want to pronounce, I'm willing to offer to be
> BDFL for this one. But a PEP is the first thing. (And IMO the key
> point of the PEP is to be very clear on what is in scope and what
> isn't - the discussions have covered a *lot* of ground and being clear
> on what's excluded will be at least as important as stating what's in
> scope).

Answering this specifically: I'm happy to be the arbiter-of-consensus
for this one, as my schedule's pretty clear right now (at least until
I head to PyCon US on the 27th).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-08 Thread Nick Coghlan 
On 8 May 2016 at 09:23, Brett Cannon  wrote:
> On Sat, May 7, 2016, 12:16 Chris Barker  wrote:
>> how is this about "bootstrapping" -- to me, bootstrapping is when you need
>> X to build X. Isn't this just regular old configuration: you need x,y to
>> build z?
>
> Sure, if you don't like the term "bootstrap" then you can call it "build
> requirements". We have not been calling it " configuration" in a general
> sense as this doesn't cover how to invoke the build step (that will probably
> be the next PEP), just what needs to be installed to even potentially do a
> build.

The reason I think "bootstrap" is a better name at this point than
"build" is that there are actually three commands we're installing the
relevant dependencies for:

* egg_info/dist_info (i.e. metadata generation)
* sdist (i.e. archive generation)
* bdist_wheel (i.e. building)

The bootstrapping at the moment is taken care of by "assume everything
uses setuptools, install setuptools by default, if you want to use
something else, use setuptools to define and retrieve it".

The new metadata aims to take the place of setuptools in that
bootstrapping process: if the software publisher so chooses, they'll
be able to both create an sdist from a source tree and a wheel archive
from an sdist without ever installing setuptools. (Of course, one or
more of their dependencies are likely to bring in setuptools anyway
for the foreseeable future, but at the level of their own project
they'll be able to ignore it)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-07 Thread Brett Cannon 
On Sat, May 7, 2016, 12:16 Chris Barker  wrote:

> On Sat, May 7, 2016 at 11:18 AM, Brett Cannon  wrote:
>
>> What fields there will be and their semantics ...
>>
>>1. Format version (so just deciding on a name -- which also includes
>>   whether it should be top-level or in a subsection -- and initial value)
>>   2. The actual bootstrap field (so its name and what to do if a
>>   dependency is already installed but at a version that doesn't match 
>> what
>>   the bootstrap specification asks for)
>>
>> Am I missing anything?
>>
>
> So what is this new configuration file supposed to cover?
>

How to specify what has to be installed to simply build a project, e.g. is
setuptools needed to run setup.py, and if so what version?

All the package meta-data? i.e. everything that would be needed by a
> package manager to properly install the package?
>


> or the build meta-data: everything needed by the build system to build the
> package?
>


> both in one file?
>
> And am missing something?
>

You're missing that you're talking several PEPs down the road. :) Right now
all we are discussing is how to specify what build tools a project needs
(historically setuptools, but in the future it could be flit or something
else).

how is this about "bootstrapping" -- to me, bootstrapping is when you need
> X to build X. Isn't this just regular old configuration: you need x,y to
> build z?
>

Sure, if you don't like the term "bootstrap" then you can call it "build
requirements". We have not been calling it " configuration" in a general
sense as this doesn't cover how to invoke the build step (that will
probably be the next PEP), just what needs to be installed to even
potentially do a build.

-Brett



> -CHB
>
>
>
>
>
>
>
>> And since I keep pushing on this I'm willing to be a co-author on any PEP
>> if there's no hard deadline in getting the PEP written (i.e. I can help
>> write the prose, but I don't have the time to do the coding as this will be
>> the fourth PEP I have going in some state; got to catch up to Nick's 35
>> PEPs somehow ;).
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(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.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-07 Thread Chris Barker 
On Sat, May 7, 2016 at 11:18 AM, Brett Cannon  wrote:

> What fields there will be and their semantics ...
>
>1. Format version (so just deciding on a name -- which also includes
>   whether it should be top-level or in a subsection -- and initial value)
>   2. The actual bootstrap field (so its name and what to do if a
>   dependency is already installed but at a version that doesn't match what
>   the bootstrap specification asks for)
>
> Am I missing anything?
>

So what is this new configuration file supposed to cover? All the package
meta-data? i.e. everything that would be needed by a package manager to
properly install the package?

or the build meta-data: everything needed by the build system to build the
package?

both in one file?

And am missing something? how is this about "bootstrapping" -- to me,
bootstrapping is when you need X to build X. Isn't this just regular old
configuration: you need x,y to build z?

-CHB







> And since I keep pushing on this I'm willing to be a co-author on any PEP
> if there's no hard deadline in getting the PEP written (i.e. I can help
> write the prose, but I don't have the time to do the coding as this will be
> the fourth PEP I have going in some state; got to catch up to Nick's 35
> PEPs somehow ;).
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-07 Thread Brett Cannon 
On Fri, 6 May 2016 at 16:58 Nathaniel Smith  wrote:

> On Fri, May 6, 2016 at 11:14 AM, Brett Cannon  wrote:
> >
> >
> > On Fri, 6 May 2016 at 09:40 Donald Stufft  wrote:
> >>
> >>
> >> On May 6, 2016, at 12:36 PM, Brett Cannon  wrote:
> >>
> >> So who is the BDFL on this decision? It seems we need someone to stop
> the
> >> bikeshedding on the field name and what file is going to house this
> >> configuration data. And do we need someone to write a PEP for this
> proposal
> >> to have something to target?
> >>
> >>
> >> We need someone to write the PEP and someone to offer to be BDFL for it.
> >> For this particular change the default would be Nick for BDFL but if
> he’s
> >> busy someone else can take it over for this PEP. Though I think we need
> >> someone writing an actual PEP first.
> >
> >
> > OK, assuming the Nick will be pronouncing, who wants to write the PEP?
>

And Paul also stepped forward to pronounce if Nick didn't want to, so we
have the role of Great Decider covered one way or another.


>
> I've just been writing up a comparison of the different file formats,
> partly in case it's useful to others and partly just for my own use in
> looking at them against each other and seeing how much it actually
> matters. This might also be reusable for the
> rationale/rejected-alternatives section of a PEP, if anyone wants it,
> or I could go ahead and add a few paragraphs to turn it into a proper
> PEP.
>

 What does the PEP need to cover?

   1. The syntax of the file (which based on the replies to your great
   overview, Nathaniel, looks to be TOML).
   2. The name of the file (although I'm assuming it will be setup.* out of
   tradition, probably setup.toml if TOML wins the format battle).
   3. What fields there will be and their semantics ...
   1. Format version (so just deciding on a name -- which also includes
  whether it should be top-level or in a subsection -- and initial value)
  2. The actual bootstrap field (so its name and what to do if a
  dependency is already installed but at a version that doesn't match what
  the bootstrap specification asks for)

Am I missing anything? And since I keep pushing on this I'm willing to be a
co-author on any PEP if there's no hard deadline in getting the PEP written
(i.e. I can help write the prose, but I don't have the time to do the
coding as this will be the fourth PEP I have going in some state; got to
catch up to Nick's 35 PEPs somehow ;).
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-06 Thread Nathaniel Smith 
On Fri, May 6, 2016 at 11:14 AM, Brett Cannon  wrote:
>
>
> On Fri, 6 May 2016 at 09:40 Donald Stufft  wrote:
>>
>>
>> On May 6, 2016, at 12:36 PM, Brett Cannon  wrote:
>>
>> So who is the BDFL on this decision? It seems we need someone to stop the
>> bikeshedding on the field name and what file is going to house this
>> configuration data. And do we need someone to write a PEP for this proposal
>> to have something to target?
>>
>>
>> We need someone to write the PEP and someone to offer to be BDFL for it.
>> For this particular change the default would be Nick for BDFL but if he’s
>> busy someone else can take it over for this PEP. Though I think we need
>> someone writing an actual PEP first.
>
>
> OK, assuming the Nick will be pronouncing, who wants to write the PEP?

I've just been writing up a comparison of the different file formats,
partly in case it's useful to others and partly just for my own use in
looking at them against each other and seeing how much it actually
matters. This might also be reusable for the
rationale/rejected-alternatives section of a PEP, if anyone wants it,
or I could go ahead and add a few paragraphs to turn it into a proper
PEP.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-06 Thread Paul Moore 
On 6 May 2016 at 19:14, Brett Cannon  wrote:
> On Fri, 6 May 2016 at 09:40 Donald Stufft  wrote:
>>
>>
>> On May 6, 2016, at 12:36 PM, Brett Cannon  wrote:
>>
>> So who is the BDFL on this decision? It seems we need someone to stop the
>> bikeshedding on the field name and what file is going to house this
>> configuration data. And do we need someone to write a PEP for this proposal
>> to have something to target?
>>
>>
>> We need someone to write the PEP and someone to offer to be BDFL for it.
>> For this particular change the default would be Nick for BDFL but if he’s
>> busy someone else can take it over for this PEP. Though I think we need
>> someone writing an actual PEP first.
>
>
> OK, assuming the Nick will be pronouncing, who wants to write the PEP?

... and if Nick doesn't want to pronounce, I'm willing to offer to be
BDFL for this one. But a PEP is the first thing. (And IMO the key
point of the PEP is to be very clear on what is in scope and what
isn't - the discussions have covered a *lot* of ground and being clear
on what's excluded will be at least as important as stating what's in
scope).

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-06 Thread Brett Cannon 
On Fri, 6 May 2016 at 09:40 Donald Stufft  wrote:

>
> On May 6, 2016, at 12:36 PM, Brett Cannon  wrote:
>
> So who is the BDFL on this decision? It seems we need someone to stop the
> bikeshedding on the field name and what file is going to house this
> configuration data. And do we need someone to write a PEP for this proposal
> to have something to target?
>
>
> We need someone to write the PEP and someone to offer to be BDFL for it.
> For this particular change the default would be Nick for BDFL but if he’s
> busy someone else can take it over for this PEP. Though I think we need
> someone writing an actual PEP first.
>

OK, assuming the Nick will be pronouncing, who wants to write the PEP?
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-06 Thread Donald Stufft 

> On May 6, 2016, at 12:36 PM, Brett Cannon  wrote:
> 
> So who is the BDFL on this decision? It seems we need someone to stop the 
> bikeshedding on the field name and what file is going to house this 
> configuration data. And do we need someone to write a PEP for this proposal 
> to have something to target?


We need someone to write the PEP and someone to offer to be BDFL for it. For 
this particular change the default would be Nick for BDFL but if he’s busy 
someone else can take it over for this PEP. Though I think we need someone 
writing an actual PEP first.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

2016-05-06 Thread Brett Cannon 
The emails seem to have reached an equilibrium point of bikeshedding on the
(bootstrap|setup)_requires issue that is being discussed (as Daniel points
out below, this has nothing to do with how building works and instead is
only about statically declaring what tools need to be installed to simply
run your builder to do whatever the heck it wants; this is the first baby
step to build decoupling/customization).

So who is the BDFL on this decision? It seems we need someone to stop the
bikeshedding on the field name and what file is going to house this
configuration data. And do we need someone to write a PEP for this proposal
to have something to target?

On Thu, 5 May 2016 at 13:54 Daniel Holth  wrote:

> 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 
> 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  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(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
>>
>