Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Marcus Smith]

>
>
> - Will allow for both static and dynamic specification of build
> dependencies


I think you need to fill in the story on dynamic dependencies, or otherwise
this PEP will be a mystery to most people.

I *think* I understand your motivation for this, based on hearing your plan
(in another thread) of putting c libs into wheels, and actually declaring
them as dependencies... and because these libs can vary based on build
settings,  your dependencies are "dynamic"... but all that needs to be
explained in the PEP

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

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Daniel Holth]

Nathaniel,

I'm not sure what the software is supposed to do with fine grained dynamic
metadata that would make very much sense to the end user. I think you could
probably get away with a single flag Dynamic: true / false. Iff true, pip
runs the dist-info command after installing bootstrap dependencies. You
could still complain if the name & version changed. Of course in a VCS
checkout or during development you probably always want the
regenerate-metadata behavior.

On Wed, Oct 28, 2015 at 5:18 AM Nathaniel Smith  wrote:

> On Tue, Oct 27, 2015 at 7:00 AM, David Cournapeau 
> wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 1:12 PM, Daniel Holth  wrote:
> >>
> >> The drawback of .zip is file size since it compresses each file
> >> individually rather than giving the compression algorithm a larger
> input,
> >> it's a great format otherwise. Ubiquitous including Apple iOS packages,
> >> Java, word processor file formats. And most Python packages are small.
> >
> >
> > I don't really buy the indexing advantages, especially w/ the current
> > implementation of zipfile in python (e.g. loading the whole set of
> archives
> > at creation time)
>
> Can you elaborate about what you mean? AFAICT from a quick skim of the
> source code, zipfile does eagerly read in the table of contents for
> the zip file (i.e., it reads out the list of files and their
> metadata), but no actual files are decompressed until you ask for them
> individually, and when you do request a specific file then it can be
> accessed in O(1) time. This is really different from .tar.gz, where
> you have to decompress the entire archive just to get a list of files,
> and then you need to decompress the whole thing again each time you
> want to access a single file inside.
>
> (Regarding the size thing, yeah, .tar.gz is smaller, and .tar.bz2
> smaller than that, and .tar.xz smaller again, ... but this doesn't
> strike me as an argument for throwing up our hands and leaving the
> choice to individual projects, because it's not like they know what
> the optimal trade-off is either. IMO we should pick one, and zip is
> Good Enough.)
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Ionel Cristian Mărieș]

On Mon, Oct 26, 2015 at 8:04 AM, Nathaniel Smith  wrote:

> [TBD: should builds be performed in a fully isolated environment, or
> should they get access to packages that are already installed in the
> target install environment? The former simplifies a number of things,
> but Robert was skeptical it would be possible.]
>

​Would be wasteful not to allow it. But then, some people might want
isolation. Whom should be able to switch isolation on? Users? Publishers?​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Nick Coghlan]

On 28 Oct 2015 10:08, "Nathaniel Smith"  wrote:
>Though it may well make sense for
> the PyPA packaging guide to add a set of best-practice guidelines for
> build system implementors.

What would be really nice is if the new specification came with a
behavioural test suite (e.g. defined with a project like behave) that a
build system developer or project owner could run to check all relevant pip
commands are handled correctly for a given package.

A spec can be ambiguous, but a behavioural test suite sets a minimum bar
that build systems can readily check themselves against.

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

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Nathaniel Smith]

On Tue, Oct 27, 2015 at 3:43 AM, Paul Moore  wrote:
>
> On 26 October 2015 at 06:04, Nathaniel Smith  wrote:
> > Here's a second round of text towards making a build-system
> > independent interface between pip and source trees/sdists. My idea
> > this time is to take a divide-and-conquer approach: this text tries to
> > summarize all the stuff that it seemed like we had mostly reached
> > consensus on in the previous thread + call, with blank chunks marked
> > "TBD" where there are specific points that still need To Be
> > Determined. So my hope is that everyone will read what's here and
> > agree that it's great as far as it goes, and then we can go through
> > and fill in each missing piece one at a time.
>
> I'll comment on what's here, but ignore the TBD items - I'd rather (as
> you suggest) leave discussion of those details till the basic idea is
> agreed.
>
> > Abstract
> > 
> >
> > Distutils delenda est.
>
> While this makes a nice tagline, I'd rather something less negative.
> Distutils does not "need" to be destroyed. It's perfectly adequate
> (although hardly user friendly) for a lot of cases - I'd be willing to
> suggest *most* users can work just fine with distutils.
>
> I'm not a fan of distutils, but I'd prefer it if we kept the rhetoric
> limited - as Nick pointed out this whole area is as much a political
> issue as a technical one.
>
> > Extended abstract
> > =
> >
> > While ``distutils`` / ``setuptools`` have taken us a long way, they
> > suffer from three serious problems: (a) they're missing important
> > features like autoconfiguration and usable build-time dependency
> > declaration, (b) extending them is quirky, complicated, and fragile,
> > (c) it's very difficult to use anything else, because they provide the
> > standard interface for installing python packages expected by both
> > users and installation tools like ``pip``.
>
> Again, this is overstated. You very nearly lost me right here - people
> won't read the details of the proposal if they disagree with the
> abstract(s). Specifically:
>
> * The features in (a) are only important to *some* parts of the
> community. The scientific community is the major one, and is a huge
> influence over the direction we want to go in, but again, not crucial
> to many people. And even where they might be useful (e.g., Windows
> users building pyyaml, lxml, pillow, ...) the description implies
> "working out what's there" rather than "allowing users to easily
> manage non-Python dependencies", which gives the wrong impression.
>
> * The features in (b) are highly specialised. Very few people extend
> setuptools/distutils. And those who do, have often invested a lot of
> effort in doing so. Sure, they'd rather not have needed to, but now
> that they have, a replacement system simply means that work is lost.
> Arguably, fixing (b) is only useful for people (like the scientific
> community) who have needed to extend setuptools and have been unable
> to achieve their goals that way. That's an even smaller part of the
> community.
>
> > Previous efforts (e.g. distutils2 or setuptools itself) have attempted
> > to solve problems (a) and/or (b). We propose to solve (c).
>
> Agreed - this is a good approach. But it's at odds with your abstract,
> which says distutils must die. Here you're saying you want to allow
> people to keep using distutils but allow people with specialised needs
> to choose an alternative. Or are you offering an alternative to people
> who use distutils?
>
> The whole of the above is confusing on the face of it. The details
> below clarify a lot, as does knowing how the previous discussions have
> gone. But it would help a lot if the introduction to this PEP were
> clearer.

Fair enough, I'll dial it back. :-)

My personal prediction is that within a year of this support becoming
widespread, we'll see build systems that are just better than
distutils on all axes for all projects, not just the ones with weird
specialised needs -- AFAICT the distutils architectures has remained
basically unchanged since Python 2.0, and we've gained a bit more
experience with Python packaging in the last 15 years :-). But yeah,
sure, if you think it'll bother people then there's no point in that.

> > The goal of this PEP is get distutils-sig out of the business of being
> > a gatekeeper for Python build systems. If you want to use distutils,
> > great; if you want to use something else, then that should be easy to
> > do using standardized methods. The difficulty of interfacing with
> > distutils means that there aren't many such systems right now, but to
> > give a sense of what we're thinking about see `flit
> > `_ or `bento
> > `_. Fortunately, wheels have now
> > solved many of the hard problems here -- e.g. it's no longer necessary
> > that a build system also know about every possible installation
> > 

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Nathaniel Smith]

On Tue, Oct 27, 2015 at 7:00 AM, David Cournapeau  wrote:
>
>
> On Tue, Oct 27, 2015 at 1:12 PM, Daniel Holth  wrote:
>>
>> The drawback of .zip is file size since it compresses each file
>> individually rather than giving the compression algorithm a larger input,
>> it's a great format otherwise. Ubiquitous including Apple iOS packages,
>> Java, word processor file formats. And most Python packages are small.
>
>
> I don't really buy the indexing advantages, especially w/ the current
> implementation of zipfile in python (e.g. loading the whole set of archives
> at creation time)

Can you elaborate about what you mean? AFAICT from a quick skim of the
source code, zipfile does eagerly read in the table of contents for
the zip file (i.e., it reads out the list of files and their
metadata), but no actual files are decompressed until you ask for them
individually, and when you do request a specific file then it can be
accessed in O(1) time. This is really different from .tar.gz, where
you have to decompress the entire archive just to get a list of files,
and then you need to decompress the whole thing again each time you
want to access a single file inside.

(Regarding the size thing, yeah, .tar.gz is smaller, and .tar.bz2
smaller than that, and .tar.xz smaller again, ... but this doesn't
strike me as an argument for throwing up our hands and leaving the
choice to individual projects, because it's not like they know what
the optimal trade-off is either. IMO we should pick one, and zip is
Good Enough.)

-n

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

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Ionel Cristian Mărieș]

On Mon, Oct 26, 2015 at 8:04 AM, Nathaniel Smith  wrote:

> When this sdist is built, the resulting wheel MUST have metadata
> which is identical to the metadata present in this file, except that
> any fields with value ``__SDIST_DYNAMIC__`` in the sdist may have
> arbitrary values in the wheel.
>
> A valid sdist MUST NOT use the ``__SDIST_DYNAMIC__`` mechanism for
> the package name or version (i.e., these must be given statically),
> and these MUST match the {PACKAGE} and {VERSION} of the sdist as
> described above.
>
> [TBD: do we want to forbid the use of dynamic metadata for any
> other fields? I assume PyPI will enforce some stricter rules at least,
> but I don't know if we want to make that part of the spec, or just
> part of PyPI's administrative rules.]
>

​Unless I misunderstood the core goal of this new sdist (to be able to know
the dependencies statically), it doesn't make sense to allow mixing things.
Is there an usecase for dynamic requirements​? In that situation users can
just as well use the current sdist format. There are no advantages to using
the new sdist format if your requirements are dynamic right?

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Paul Moore]

On 26 October 2015 at 06:04, Nathaniel Smith  wrote:
> Here's a second round of text towards making a build-system
> independent interface between pip and source trees/sdists. My idea
> this time is to take a divide-and-conquer approach: this text tries to
> summarize all the stuff that it seemed like we had mostly reached
> consensus on in the previous thread + call, with blank chunks marked
> "TBD" where there are specific points that still need To Be
> Determined. So my hope is that everyone will read what's here and
> agree that it's great as far as it goes, and then we can go through
> and fill in each missing piece one at a time.

I'll comment on what's here, but ignore the TBD items - I'd rather (as
you suggest) leave discussion of those details till the basic idea is
agreed.

> Abstract
> 
>
> Distutils delenda est.

While this makes a nice tagline, I'd rather something less negative.
Distutils does not "need" to be destroyed. It's perfectly adequate
(although hardly user friendly) for a lot of cases - I'd be willing to
suggest *most* users can work just fine with distutils.

I'm not a fan of distutils, but I'd prefer it if we kept the rhetoric
limited - as Nick pointed out this whole area is as much a political
issue as a technical one.

> Extended abstract
> =
>
> While ``distutils`` / ``setuptools`` have taken us a long way, they
> suffer from three serious problems: (a) they're missing important
> features like autoconfiguration and usable build-time dependency
> declaration, (b) extending them is quirky, complicated, and fragile,
> (c) it's very difficult to use anything else, because they provide the
> standard interface for installing python packages expected by both
> users and installation tools like ``pip``.

Again, this is overstated. You very nearly lost me right here - people
won't read the details of the proposal if they disagree with the
abstract(s). Specifically:

* The features in (a) are only important to *some* parts of the
community. The scientific community is the major one, and is a huge
influence over the direction we want to go in, but again, not crucial
to many people. And even where they might be useful (e.g., Windows
users building pyyaml, lxml, pillow, ...) the description implies
"working out what's there" rather than "allowing users to easily
manage non-Python dependencies", which gives the wrong impression.

* The features in (b) are highly specialised. Very few people extend
setuptools/distutils. And those who do, have often invested a lot of
effort in doing so. Sure, they'd rather not have needed to, but now
that they have, a replacement system simply means that work is lost.
Arguably, fixing (b) is only useful for people (like the scientific
community) who have needed to extend setuptools and have been unable
to achieve their goals that way. That's an even smaller part of the
community.

> Previous efforts (e.g. distutils2 or setuptools itself) have attempted
> to solve problems (a) and/or (b). We propose to solve (c).

Agreed - this is a good approach. But it's at odds with your abstract,
which says distutils must die. Here you're saying you want to allow
people to keep using distutils but allow people with specialised needs
to choose an alternative. Or are you offering an alternative to people
who use distutils?

The whole of the above is confusing on the face of it. The details
below clarify a lot, as does knowing how the previous discussions have
gone. But it would help a lot if the introduction to this PEP were
clearer.

> The goal of this PEP is get distutils-sig out of the business of being
> a gatekeeper for Python build systems. If you want to use distutils,
> great; if you want to use something else, then that should be easy to
> do using standardized methods. The difficulty of interfacing with
> distutils means that there aren't many such systems right now, but to
> give a sense of what we're thinking about see `flit
> `_ or `bento
> `_. Fortunately, wheels have now
> solved many of the hard problems here -- e.g. it's no longer necessary
> that a build system also know about every possible installation
> configuration -- so pretty much all we really need from a build system
> is that it have some way to spit out standard-compliant wheels.

OK. Although I see a risk here that if I want to build package FOO, I
now have to worry whether FOO's build system supports Windows, as well
as worrying whether FOO itself supports Windows.

There's still a role for some "gatekeeper" (not a good word IMO, maybe
"coordinator") to provide a certain level of support or review of
build systems, and a point of contact for users with build issues (the
point of this proposal is to some extent that people don't need to
*know* what build system a project uses, so suggesting everyone has to
direct issues to the correct build system support forum isn't
necessarily 

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Daniel Holth]

The drawback of .zip is file size since it compresses each file
individually rather than giving the compression algorithm a larger input,
it's a great format otherwise. Ubiquitous including Apple iOS packages,
Java, word processor file formats. And most Python packages are small.

We must do the hard work to support Unicode file names, and spaces and
accent marks in home directory names (historically a problem on Windows),
in our packaging system. It is the right thing to do. It is not the
publisher's fault that your system has broken Unicode.

On Tue, Oct 27, 2015 at 6:43 AM Paul Moore  wrote:

> On 26 October 2015 at 06:04, Nathaniel Smith  wrote:
> > Here's a second round of text towards making a build-system
> > independent interface between pip and source trees/sdists. My idea
> > this time is to take a divide-and-conquer approach: this text tries to
> > summarize all the stuff that it seemed like we had mostly reached
> > consensus on in the previous thread + call, with blank chunks marked
> > "TBD" where there are specific points that still need To Be
> > Determined. So my hope is that everyone will read what's here and
> > agree that it's great as far as it goes, and then we can go through
> > and fill in each missing piece one at a time.
>
> I'll comment on what's here, but ignore the TBD items - I'd rather (as
> you suggest) leave discussion of those details till the basic idea is
> agreed.
>
> > Abstract
> > 
> >
> > Distutils delenda est.
>
> While this makes a nice tagline, I'd rather something less negative.
> Distutils does not "need" to be destroyed. It's perfectly adequate
> (although hardly user friendly) for a lot of cases - I'd be willing to
> suggest *most* users can work just fine with distutils.
>
> I'm not a fan of distutils, but I'd prefer it if we kept the rhetoric
> limited - as Nick pointed out this whole area is as much a political
> issue as a technical one.
>
> > Extended abstract
> > =
> >
> > While ``distutils`` / ``setuptools`` have taken us a long way, they
> > suffer from three serious problems: (a) they're missing important
> > features like autoconfiguration and usable build-time dependency
> > declaration, (b) extending them is quirky, complicated, and fragile,
> > (c) it's very difficult to use anything else, because they provide the
> > standard interface for installing python packages expected by both
> > users and installation tools like ``pip``.
>
> Again, this is overstated. You very nearly lost me right here - people
> won't read the details of the proposal if they disagree with the
> abstract(s). Specifically:
>
> * The features in (a) are only important to *some* parts of the
> community. The scientific community is the major one, and is a huge
> influence over the direction we want to go in, but again, not crucial
> to many people. And even where they might be useful (e.g., Windows
> users building pyyaml, lxml, pillow, ...) the description implies
> "working out what's there" rather than "allowing users to easily
> manage non-Python dependencies", which gives the wrong impression.
>
> * The features in (b) are highly specialised. Very few people extend
> setuptools/distutils. And those who do, have often invested a lot of
> effort in doing so. Sure, they'd rather not have needed to, but now
> that they have, a replacement system simply means that work is lost.
> Arguably, fixing (b) is only useful for people (like the scientific
> community) who have needed to extend setuptools and have been unable
> to achieve their goals that way. That's an even smaller part of the
> community.
>
> > Previous efforts (e.g. distutils2 or setuptools itself) have attempted
> > to solve problems (a) and/or (b). We propose to solve (c).
>
> Agreed - this is a good approach. But it's at odds with your abstract,
> which says distutils must die. Here you're saying you want to allow
> people to keep using distutils but allow people with specialised needs
> to choose an alternative. Or are you offering an alternative to people
> who use distutils?
>
> The whole of the above is confusing on the face of it. The details
> below clarify a lot, as does knowing how the previous discussions have
> gone. But it would help a lot if the introduction to this PEP were
> clearer.
>
> > The goal of this PEP is get distutils-sig out of the business of being
> > a gatekeeper for Python build systems. If you want to use distutils,
> > great; if you want to use something else, then that should be easy to
> > do using standardized methods. The difficulty of interfacing with
> > distutils means that there aren't many such systems right now, but to
> > give a sense of what we're thinking about see `flit
> > `_ or `bento
> > `_. Fortunately, wheels have now
> > solved many of the hard problems here -- e.g. it's no longer necessary
> > that a build system also know about 

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Paul Moore]

On 27 October 2015 at 13:12, Daniel Holth  wrote:
> We must do the hard work to support Unicode file names, and spaces and
> accent marks in home directory names (historically a problem on Windows), in
> our packaging system. It is the right thing to do. It is not the publisher's
> fault that your system has broken Unicode.

In the examples I'm thinking of, the publisher used a format (.tar.gz)
that didn't properly support Unicode, in the sense that it didn't
include an encoding for the bytes it used to represent filenames. IMO,
that is something we shouldn't allow, by rejecting file formats that
don't support Unicode properly.

Whose fault it is, is not important - it's just as easy to say that
it's not the end user's fault that the publisher made an unwarranted
assumption about encodings. What's important is that things work for
everyone, and the interoperability standards don't leave room for
people to make such assumptions.

Paul

PS Consider this a retraction of my suggestion that filenames in
sdists should be pure ASCII. But still, sdists shouldn't contain files
that can't be used on target systems - e.g., 2 files whose names
differ only in case, files containing characters like :, ? or * that
are invalid on Windows... Whether this needs to be noted in the
standard, or whether it's just a case of directing users' bug reports
back to the publisher, is an open question, though.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[David Cournapeau]

On Tue, Oct 27, 2015 at 1:12 PM, Daniel Holth  wrote:

> The drawback of .zip is file size since it compresses each file
> individually rather than giving the compression algorithm a larger input,
> it's a great format otherwise. Ubiquitous including Apple iOS packages,
> Java, word processor file formats. And most Python packages are small.
>

I don't really buy the indexing advantages, especially w/ the current
implementation of zipfile in python (e.g. loading the whole set of archives
at creation time)

A common way to solve the fast metadata access from archive is to archive
separately the metadata data and data (e.g. a zipfile containing 2
zipfiles, one being the original sdist, the other one containing the
metadata).

David


> We must do the hard work to support Unicode file names, and spaces and
> accent marks in home directory names (historically a problem on Windows),
> in our packaging system. It is the right thing to do. It is not the
> publisher's fault that your system has broken Unicode.
>
> On Tue, Oct 27, 2015 at 6:43 AM Paul Moore  wrote:
>
>> On 26 October 2015 at 06:04, Nathaniel Smith  wrote:
>> > Here's a second round of text towards making a build-system
>> > independent interface between pip and source trees/sdists. My idea
>> > this time is to take a divide-and-conquer approach: this text tries to
>> > summarize all the stuff that it seemed like we had mostly reached
>> > consensus on in the previous thread + call, with blank chunks marked
>> > "TBD" where there are specific points that still need To Be
>> > Determined. So my hope is that everyone will read what's here and
>> > agree that it's great as far as it goes, and then we can go through
>> > and fill in each missing piece one at a time.
>>
>> I'll comment on what's here, but ignore the TBD items - I'd rather (as
>> you suggest) leave discussion of those details till the basic idea is
>> agreed.
>>
>> > Abstract
>> > 
>> >
>> > Distutils delenda est.
>>
>> While this makes a nice tagline, I'd rather something less negative.
>> Distutils does not "need" to be destroyed. It's perfectly adequate
>> (although hardly user friendly) for a lot of cases - I'd be willing to
>> suggest *most* users can work just fine with distutils.
>>
>> I'm not a fan of distutils, but I'd prefer it if we kept the rhetoric
>> limited - as Nick pointed out this whole area is as much a political
>> issue as a technical one.
>>
>> > Extended abstract
>> > =
>> >
>> > While ``distutils`` / ``setuptools`` have taken us a long way, they
>> > suffer from three serious problems: (a) they're missing important
>> > features like autoconfiguration and usable build-time dependency
>> > declaration, (b) extending them is quirky, complicated, and fragile,
>> > (c) it's very difficult to use anything else, because they provide the
>> > standard interface for installing python packages expected by both
>> > users and installation tools like ``pip``.
>>
>> Again, this is overstated. You very nearly lost me right here - people
>> won't read the details of the proposal if they disagree with the
>> abstract(s). Specifically:
>>
>> * The features in (a) are only important to *some* parts of the
>> community. The scientific community is the major one, and is a huge
>> influence over the direction we want to go in, but again, not crucial
>> to many people. And even where they might be useful (e.g., Windows
>> users building pyyaml, lxml, pillow, ...) the description implies
>> "working out what's there" rather than "allowing users to easily
>> manage non-Python dependencies", which gives the wrong impression.
>>
>> * The features in (b) are highly specialised. Very few people extend
>> setuptools/distutils. And those who do, have often invested a lot of
>> effort in doing so. Sure, they'd rather not have needed to, but now
>> that they have, a replacement system simply means that work is lost.
>> Arguably, fixing (b) is only useful for people (like the scientific
>> community) who have needed to extend setuptools and have been unable
>> to achieve their goals that way. That's an even smaller part of the
>> community.
>>
>> > Previous efforts (e.g. distutils2 or setuptools itself) have attempted
>> > to solve problems (a) and/or (b). We propose to solve (c).
>>
>> Agreed - this is a good approach. But it's at odds with your abstract,
>> which says distutils must die. Here you're saying you want to allow
>> people to keep using distutils but allow people with specialised needs
>> to choose an alternative. Or are you offering an alternative to people
>> who use distutils?
>>
>> The whole of the above is confusing on the face of it. The details
>> below clarify a lot, as does knowing how the previous discussions have
>> gone. But it would help a lot if the introduction to this PEP were
>> clearer.
>>
>> > The goal of this PEP is get distutils-sig out of the business of being
>> > a gatekeeper for