[Distutils] Re: New packaging security funding & NYU

[Ian Stapleton Cordasco]

This is awesome! Congratulations!

On Fri, Mar 19, 2021 at 10:30 PM Sumana Harihareswara  
wrote:
>
> Good news!
>
> New York University -- specifically Professor Justin Cappos -- and I
> have successfully asked the US National Science Foundation for a grant
> to improve Python packaging security. The NSF is awarding NYU $800,000
> over two years -- from mid-2021 to mid-2023 -- to further improve the
> pip dependency resolver and to integrate The Update Framework further
> into the packaging toolchain.
>
> https://nsf.gov/awardsearch/showAward?AWD_ID=2054692=false
>
> For what we're planning to do, what this means in the short term, an
> explanation of why NYU and the NSF are involved, and thank-yous, please
> see https://discuss.python.org/t/new-packaging-security-funding-nyu/7792 .
>
> --
> Sumana Harihareswara
> Changeset Consulting
> https://changeset.nyc
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/MUH254XTCE5EUL5YJV7ZD6HSUYNFXUD6/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/ZZBSMACFKI4QGEACWLBV4O3WKDI6PVYI/

[Distutils] Re: Unsubscribing from this list

[Ian Stapleton Cordasco]

It's also possible to moderate new members such that their first message is
flagged and a moderator has to clear that flag upon receipt of the first
message. This is why the code quality list doesn't get spam. I'm happy to
help with that here too if this list is on MM3

Sent from my phone with my typo-happy thumbs. Please excuse my brevity

On Mon, Sep 21, 2020, 09:17 Thomas Kluyver  wrote:

> If we want a one-way announcement list, I'd say we're better off either
> using pypi-announce (which already has some announcements that aren't
> strictly about PyPI), or setting up a new packaging-announce list.
>
> Thomas
>
> On Mon, 21 Sep 2020, at 15:09, Paul Ganssle wrote:
>
> Another possible middle ground between shuttering the list entirely and
> maintaining the spam would be (if possible) to close the list to new
> membership, but keep the existing list in place for the purpose of
> announcing important changes and things that need community input on the
> discourse.
>
> On 9/21/20 9:50 AM, Thomas Kluyver wrote:
> > If it's not already the case, could someone configure the list so that
> only subscribers can send messages?
> >
> > If we've already got any obvious anti-spam measures like that in place,
> then I'm starting to agree that the signal to noise ratio has fallen too
> low. Of the 10 latest conversations in the archive, 5 are spam, 2 are
> people announcing that they're leaving the list, 2 real questions getting
> no discussion, and 1 FYI about a discussion happening on Discourse.
> >
> > Thomas
> >
> > On Mon, 21 Sep 2020, at 14:33, Paul Moore wrote:
> >> I'm going to unsubscribe from this list, as it appears to be getting
> >> little but spam any more. I'll still be available on the Packaging
> >> topic on Discourse (https://discuss.python.org/c/packaging/14).
> >>
> >> To be honest, I think it's time to discontinue this list. But that's
> >> for others to decide.
> >>
> >> Paul
> >> --
> >> Distutils-SIG mailing list -- distutils-sig@python.org
> >> To unsubscribe send an email to distutils-sig-le...@python.org
> >> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> >> Message archived at
> >>
> https://mail.python.org/archives/list/distutils-sig@python.org/message/J66LYNCZKNJTJYRIAS63225Y5XJZK2CM/
> >>
> > --
> > Distutils-SIG mailing list -- distutils-sig@python.org
> > To unsubscribe send an email to distutils-sig-le...@python.org
> > https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> > Message archived at
> https://mail.python.org/archives/list/distutils-sig@python.org/message/DP7EXNLZ2GRKCSIAGCSFZWMPBD24NAUX/
>
>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/archives/list/distutils-sig@python.org/message/4AI4XHDSYMBSIV2WF3PQDPR5DSMAGIFH/
>
>
> *Attachments:*
>
>- signature.asc
>
>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/archives/list/distutils-sig@python.org/message/IW3L4VTLJAFFVLJEF6ZBQZL4FFHKSVLK/
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/DZQLA6JLMW27VHLXGTWEQQ6TOXUA5UWU/

[Distutils] Re: Archive this list & redirect conversation elsewhere?

[Ian Stapleton Cordasco]

On Thu, Jul 30, 2020 at 5:39 AM Robert Collins
 wrote:
>
>
>
> On Thu, 30 Jul 2020 at 14:52, Sumana Harihareswara  wrote:
>>
>> On 7/29/20 10:14 PM, Jeremy Stanley wrote:
>> > On 2020-07-30 07:17:03 +0530 (+0530), Pradyun Gedam wrote:
>> >> TL;DR: OK to archive this mailing list? Reply by Aug 30th.
>> > [...]
>> >
>> > I find it disappointing that there will no longer be a mailing list
>> > for discussions of Python packaging. Web forums with some E-mail
>> > integration are hardly the same. But those of us who still use
>> > E-mail (and worse, Usenet) eventually need to get out of the way of
>> > the wheels of progress lest they run us over.
>> >
>> > Many thanks to those who have maintained, moderated, and
>> > collaborated through this list over the years. It has been much
>> > appreciated.
>>
>> Jeremy, I'm not sure whether you were serious? If your disappointment is
>> only out of nostalgia, then yeah, accepting change makes sense. But if
>> your disappointment is because the Discourse experience is/will be worse
>> for your participation, then it's totally fine to speak up and tell us how.
>
>
> Discourse requires about 10x the effort to participate in the community. It's 
> "mailing list mode" sends garbled fragments of interwoved WYSIWYG documents 
> that are unintelligible - I tried it for some months when the Pyython 
> Discourse started up but had to turn it off after a while as I really 
> couldn't effectively tell what was being said in a conversation that comes in 
> via it.

I definitely agree with this.

>
> And its so siloed, I may as well not be in the conversation at all: I have to 
> actively go and log into the website to look and see what new conversations 
> are happening, which in my time poor situation just doesn't happen. So, for 
> all intents and purposes, I'm not participating in any conversation in 
> Discourse at all, except for a rare helicopter drop-in when someone pings me 
> on email or Twitter or Slack or Discord to say 'hey, you should comment on 
> '.

With email, I don't have to monitor heavily what topics I'm subscribed
to and if someone starts a discussion I'm uninterested in, I can mute
it. With Discourse it hasn't respected my desires to unsubscribe from
a thread's notifications and I still get emails from a thread from
Rust's Discourse from 2 years ago.

I have generally the same sentiment as Jeremy and Rob though. I'm more
or less an emeritus member of this community (although I still try to
collaborate on Twine and keep up with general packaging discussions
and direction). Things have already started moving to Discourse though
and surprising me on twine because no one remembered me as part of the
team. So, Discourse has already made me want to work on Twine less.

I will say that my impression of the ability to moderate Discourse is
lower friction/less difficult than to moderate a mailing list
(although mailman 3 is pretty great). I don't think that's a point in
Discourse's favor to be overlooked.

>
> I full well recognise the advantage that these properties have when dealing 
> with a bulk of (largely) newcomers whose community use case is to sample 
> discussion: to find one or two things that have been said previously via 
> search, ask some questions to get a problem solved, and then move on.
>
> Relatively few of those users will be publishing packages though; even with 
> the rise of docker : consuming Python in a local script or workbook is still 
> the majority use case I think, so the bulk of the work we do affects a 
> (large) fraction of users, and most of those users are experienced by the 
> time they need our assistance.
>
>> Pradyun, thanks for starting this conversation.
>>
>> I am definitely interested in consolidating our conversational channels
>> and reducing fragmentation, but I have substantial reservations about
>> taking this particular step:
>>
>> * The majority of information overwhelm in my PyPA-related life is
>> because of GitHub repo and issue sprawl -- if we're going to put energy
>> into pruning sprawling communications venues, I would prefer that we
>> spend some time inventorying all the teams, shutting some down, and
>> locking noisy issues/repositories.
>
>
> Agreed with the above.
>
>>
>> * I would like to know, of our ~700 list members, how many of them have
>> serious problems using Discourse -- accessibility, user experience,
>> sheer tech problems, etc. I suspect that we have several members in that
>> category, some who contribute to packaging, some who lurk so they can
>> stay apprised and bridge to other communities (distributions, major
>> packages, etc.).
>
>
> I have contributed a fair degree in the past; I'm largely if not entirely 
> emeritus at this point - I get to code only from time to time in my day job, 
> and then it is rarely Python. I like to stay in touch, both because I can 
> provide some institutional continuity, but also I do enjoy helping from time 
> to time, when I can.
>
> I hope these 

[Distutils] Re: Provide a way to bundle and extract license files

[Ian Stapleton Cordasco]

Forgive me if I'm missing something but doesn't license-file provides this
functionality (see https://stackoverflow.com/a/48691876) for an example.

I surmise not enough people use it although it's readily available?

Sent from my phone with my typo-happy thumbs. Please excuse my brevity

On Sat, Feb 22, 2020, 13:35 Steve Jorgensen  wrote:

> Steve Jorgensen wrote:
> > The project I am working on now needs to include license files for all
> of the 3rd party
> > code that it includes. Since license files are not included in
> distribution packages, the
> > process for doing this is exceedingly complex, error prone, and in some
> cases, impossible.
> > The build process builds URLs to license files in package source code
> repositories based
> > on version number, but this is dependent upon several things…
> >
> > The source code repository is accessible via the Internet and still
> exists.
> > There is a tag for each version (not always true).
> > Tags follow a consistent naming pattern with respect to version numbers
> (not always
> > true).
> >
> > I believe that it makes sense to provide a standard means for
> distribution packages to
> > include license files and then encourage package authors to use it.
>
> This would be similar to `{ "license" : "SEE LICENSE IN " }` in
> an npm package. See also https://www.npmjs.com/package/license-extractor .
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/archives/list/distutils-sig@python.org/message/CSS5L2D3U7WNK2TOOLFIPE5X62WS7TO6/
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/K3K73F57PPOYBFT64WJEAIQ6T6J57UAZ/

[Distutils] Re: parver: parse and manipulate PEP 440 version numbers

[Ian Stapleton Cordasco]

How is this different from PyPA's packaging library which has a parser
for PEP 440 versions?
https://github.com/pypa/packaging/blob/master/packaging/version.py

On Thu, Feb 20, 2020 at 5:34 PM Frazer McLean  wrote:
>
> Hi,
>
> parver is my package for parsing and manipulating PEP 440 version
> numbers. I have just released version 0.3.
>
> For more information:
>
> PyPI: https://pypi.org/project/parver/
> Repository: https://github.com/RazerM/parver
> Documentation: https://parver.readthedocs.io/en/latest/
>
> Thanks,
>
> Frazer
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/IH3ADVUMCGQP3LE3X7J72LXB6HGTR2KC/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/ZTO5DMQJUE5SDGRXGLJJ6BQNOV2WPEOH/

[Distutils] Re: Why lockbot?

[Ian Stapleton Cordasco]

So the API endpoint to lock an issue absolutely does not require
comments on each thing. I think the idea is probably that it's easier
to understand that this was an automated process doing this rather
than being used in the vein of GitHub's moderation (which doesn't
account for anything other than abuse).

For those who are interested, the lock API is
https://developer.github.com/v3/issues/#lock-an-issue

On Sun, Jun 2, 2019 at 6:40 AM Paul Moore  wrote:
>
> One thought - is it possible in github to subscribe to "everything
> that isn't closed"? I couldn't see such an issue but that would (a)
> let me ignore the lockbot messages, and (b) let me ignore close
> threads so I wouldn't even need lockbot.
>
> Paul
>
> On Sun, 2 Jun 2019 at 12:26, Paul Moore  wrote:
> >
> > The bot has just been enabled, and it's catching up on historical bugs
> > (which can't be done all in one go, as rate limits would hit us).
> > Hopefully it should die down in a few days.
> >
> > Whether there's a way to tell github not to send such notifications,
> > or whether it's possible for us to configure the bot to lock the
> > thread but not add a comment, I don't know.
> > Paul
> >
> > On Sun, 2 Jun 2019 at 09:12, Robert Collins  
> > wrote:
> > >
> > > Seems like most of the pip bugmail I get now is lockbot messages
> > > telling me that a bug that hasn't received any discussion for a long
> > > time now can't have any more discussion. Is that really needed? The
> > > github UI shows the lock status of bugs itself...
> > >
> > > -Rob
> > > --
> > > Distutils-SIG mailing list -- distutils-sig@python.org
> > > To unsubscribe send an email to distutils-sig-le...@python.org
> > > https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> > > Message archived at 
> > > https://mail.python.org/archives/list/distutils-sig@python.org/message/2Z4THA3D3JQSUYVK7YNKVYAKHVCZJZ7Y/
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/ROZ4Z2TYDE62XZEOHGJV635ZB6CCMZAW/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/KXWKPVGM64LNUHUGGRHVTSKDXY6HCO4O/

[Distutils] Re: Should an sdist/MANIFEST.in include docs and tests?

[Ian Stapleton Cordasco]

Quoting Bert, up-thread "Our sdists are pretty big as a result."

Some of my projects have very large test suites that would bloat the
sdist, and I've worked on many more with the same issue. I don't think
we can just wave our hands and say "sdists don't end up particularly
big so we can ignore those people". Further more, we can't quite know
how people are using sdists and wheels anywhere other than via PyPI
download statistics (which if I remember correctly, are lossy).

It's also worth noting that there was a different distribution format,
previously, not named an "sdist" that was a specific repository
archive. The problem occurs now that PyPI only allows that or sdist
and that the other format is neither pip-installable nor intended to
be a distribution (versus a version artifact).
On Mon, Sep 10, 2018 at 2:35 PM Thomas Kluyver  wrote:
>
> On Mon, Sep 10, 2018, at 1:06 PM, Ian Stapleton Cordasco wrote:
>
> It seems silly that we're not also considering the portions of the world with 
> terrible internet when making this decision. Giant sdists make their lives 
> orders of magnitude worse for the benefit of maybe 20-30 people who tend to 
> use the tests.
>
>
> We should certainly consider internet speeds across the world in general, but 
> I don't think it's that important to this particular discussion. In most 
> cases, users who just want to install and use a package can get it as a 
> wheel, so what we do with sdists doesn't matter to them. And there aren't 
> many projects where adding tests and docs makes an order of magnitude 
> difference to the archive size.
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/BNQNZ35UKT7W6J2KVXKB2DUSH34RIVYU/

[Distutils] Re: Should an sdist/MANIFEST.in include docs and tests?

[Ian Stapleton Cordasco]

And yet reality is that many downstreams can't rely on an sdist to include
that because it is an installable format. Not everything does include those
files. I tend to view an sdist as a similar format to wheels. I've been
bullied into including the tests and docs on occasion, but that has never
actually provided benefit to more than a handful of folks. It seems silly
that we're not also considering the portions of the world with terrible
internet when making this decision. Giant sdists make their lives orders of
magnitude worse for the benefit of maybe 20-30 people who tend to use the
tests.

Sent from my phone with my typo-happy thumbs. Please excuse my brevity

On Mon, Sep 10, 2018, 04:43 Freddy Rietdijk  wrote:

> As a Nixpkgs Python maintainer I often ask projects to include their tests
> in the sdist so we can run them when packaging. I prefer it also when an
> sdist basically represents a snapshot of a repository.
>
> On Mon, Sep 10, 2018 at 8:08 AM, Thomas Kluyver 
> wrote:
>
>> On Mon, Sep 10, 2018, at 12:33 AM, Bert JW Regeer wrote:
>>
>> Speaking as a maintainer of various different packages for the Pylons
>> project, we include the following in our sdists:
>>
>> - source code for the package
>> - tests for the package
>> - documentation for the package
>>
>> and of course the license/history/changelog/everything you'd
>> theoretically need to create a fork (minus .git). Our sdists are pretty big
>> as a result.
>>
>>
>> When I was working out how Flit could build sdists without a MANIFEST.in,
>> I settled on the idea that an sdist should be more or less a static
>> equivalent of checking out the git tag for that release. So if a project
>> lost its VCS history, all the files from release versions would still be in
>> sdists. That means all the source files are there (like rst docs), but not
>> generated files (like Sphinx HTML output).
>>
>> Now that 'pip install' gets wheels where possible, there's less pressure
>> to make sdists as slim as possible, because far fewer people will need to
>> wait for them to download.
>>
>> --
>> Distutils-SIG mailing list -- distutils-sig@python.org
>> To unsubscribe send an email to distutils-sig-le...@python.org
>> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
>> Message archived at
>> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/FOX6YWO2NPY6ONE4RDKVD5JCTWSTIDG3/
>>
>>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/NRQ3JDCAJK5CLNGZQV3WXCCXE2EQE5V5/
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/ENYFUNLLCSYKIF55BGYECXBB62I7OISH/

[Distutils]Re: pypi/twine complains about license

[Ian Stapleton Cordasco]

Hi there Robin,

I'm going to try to reply in-line.

Sent from my phone with my typo-happy thumbs.

On Wed, Jul 11, 2018, 11:17 Robin Becker  wrote:

> After release of Python-3.7 I wanted to upload to pypi a newly built
> version of a C-extension which already has been migrated to
> the new site.
>
>
> $ twine --version
> twine version 1.11.0 (pkginfo: 1.4.2, requests: 2.18.1, setuptools: 36.2.0,
> requests-toolbelt: 0.8.0, tqdm: 4.14.0)
> $ twine upload *.whl
> Uploading distributions to https://upload.pypi.org/legacy/
> Uploading pyRXP-2.1.1-cp37-cp37m-manylinux1_i686.whl
> 100%||
> 104K/104K [00:00<00:00,
> 141KB/s]
> HTTPError: 400 Client Error: Invalid value for classifiers. Error:
> 'License :: OSI Approved :: ReportLab BSD derived' is not a
> valid choice for this field for url: https://upload.pypi.org/legacy/


This indicates that you're using a classifier which isn't actually
registered. That causes the upload to be rejected. It is equivalent to
trying to use a classifier that might claim support for Python 2.8


>
> 1) I think it is completely wrong for twine/pypi to fail to upload because
> of the license field. The license is derived from BSD
> and the same string is present in the previously uploaded versions of this
> package. What are valid licenses? Presumably pypi is
> now a gatekeeper for the license police.
>

This seems harmfully rude and presumptive. I've explained the problem
you're encountering above. Please assume the best going forward


>
> 2) I looked in vain on the new pypi.org site for a manual upload
> mechanism. Is this now frowned on?
>

I'm not sure why a manual upload would be preferable here.


> 3) I was able to upload the same package several times without error; does
> this mean I am overwriting the file?
>

This seems unrelated and there's no information here to explain the
question. Given that a file can not be deleted and re-uploaded to PyPI I'm
guessing that you uploaded it once successfully and continue to run the
same command. PyPI is ignoring those most likely or you're using twine's
--skip-existing flag which allows uploads of more than one file to continue
even if some are already uploaded

-- 
> Robin Becker
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/RAFVT2Z23NZOAVURYKRASZTBWEGWSUDI/
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/HUPYQWS4M6VGBUR2WW2IOR57642XCVG3/

Re: [Distutils] Conditionless setup.py

[Ian Stapleton Cordasco]

Except that OpenStack frequently rejects outside use cases as I learned as
an OpenStack developer who tried to improve PBR. Sadly it will never be
seen as a global solution as long as that continues

On Aug 25, 2017 6:32 AM, "Jeremy Stanley"  wrote:

> On 2017-08-25 10:50:11 +0100 (+0100), Paul Moore wrote:
> [...]
> > once PEP 517 is implemented and as flit gains popularity, I fully
> > expect more and more projects to use a static data structure for
> > their metadata (flit.ini, specifically).
>
> This has also been possible for years already using either PBR or
> distutils2. For example, hundreds of Python packages produced by the
> OpenStack community use a branchless boilerplate setup.py which
> declares a setup_requires on the pbr package, and then everything
> else goes into an INI-formatted setup.cfg file (except for
> install_requires which are drawn from requirements.txt instead).
> --
> Jeremy Stanley
>
> ___
> 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