Hi,
Also, just noticed that 0.7.3 is available as .zip, but not as .tar.gz
like the others are.
Liam
--
Liam Kirsher
PGP: http://liam.numenet.com/pgp/
___
Distutils-SIG maillist - Distutils-SIG@python.org
On Tue, Jul 16, 2013 at 13:57 -0400, Donald Stufft wrote:
On Jul 16, 2013, at 5:19 AM, holger krekel hol...@merlinux.eu wrote:
I am considering implementing gpg-signing and verification of release files
for devpi. Rather than requiring package authors to sign their release
files, i am
Nick Coghlan ncoghlan at gmail.com writes:
Actually, it may be better to have a top level scripts field, distinct
from a general export mechanism.
I'm seeing value in an exports mechanism, though.
The exports functionality is important and used enough to warrant support in
the PEP, and not
On Jul 17, 2013, at 3:40 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
It has been suggested by PJE that the
exports information should be in a separate file for speed of searching -
though that suggestion was made in a pre-JSON world, where the speed of
parsing the metadata wasn't
holger krekel holger at merlinux.eu writes:
about existing schemes/efforts. I guess most Linux distros do it already
so if nothing comes up here PyPI-specific (what is the status of TUF, btw?)
i am going to look into the distro's working models.
ISTM it works for distros because they're the
Donald Stufft donald at stufft.io writes:
I don't think it was speed of parsing the file that was his concern,
rather that
if it's a separate file that only exists when there are entry points, then you
don't have to open a file for every installed distribution.
OK. In that case, exports.json
On 16-07-13 19:15, Liam Kirsher wrote:
ec2-54-245-36-62.us-west-2.compute.amazonaws.com ImportError: No module
named setuptools
My guess is that there's a left-over distribute somewhere. Probably an
egg-link in some dist-packages or site-packages directory. I had a
problem like that too.
On Wed, Jul 17, 2013 at 07:48 +, Vinay Sajip wrote:
holger krekel holger at merlinux.eu writes:
about existing schemes/efforts. I guess most Linux distros do it already
so if nothing comes up here PyPI-specific (what is the status of TUF, btw?)
i am going to look into the distro's
On 17 Jul 2013 18:17, holger krekel hol...@merlinux.eu wrote:
On Wed, Jul 17, 2013 at 07:48 +, Vinay Sajip wrote:
holger krekel holger at merlinux.eu writes:
about existing schemes/efforts. I guess most Linux distros do it
already
so if nothing comes up here PyPI-specific (what is
On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote:
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this has anything to do with pip? As far as
compiling goes all pip does is call
On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote:
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this has anything to do with pip? As far as
compiling goes all pip does is
On 16 July 2013 14:40, Nick Coghlan ncogh...@gmail.com wrote:
The latest version of PEP 426 is up at
http://www.python.org/dev/peps/pep-0426/
Just looking at the Build requires section I found myself wondering:
is there any way to say that e.g. a C compiler is required for
building, or a
On 17 July 2013 12:01, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 16 July 2013 14:40, Nick Coghlan ncogh...@gmail.com wrote:
The latest version of PEP 426 is up at
http://www.python.org/dev/peps/pep-0426/
Just looking at the Build requires section I found myself wondering:
is
On 17 July 2013 12:10, Paul Moore p.f.mo...@gmail.com wrote:
I can't imagine it's practical to auto-install a C compiler
Why not?
- or even to check for one before building.
But I can see it being useful for
introspection purposes to know about this type of requirement. (A C compiler
On 17 July 2013 20:00, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote:
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this
On 17 July 2013 21:45, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 17 July 2013 12:10, Paul Moore p.f.mo...@gmail.com wrote:
I can't imagine it's practical to auto-install a C compiler
Why not?
- or even to check for one before building.
But I can see it being useful for
Hi,
I suspect the problem is with the changing infrastructure of
setuptools-distribute.
I'm happy to hear of this merge, thank you for all of you, who contributed to
these tools.
https://python-packaging-user-guide.readthedocs.org/en/latest/current.html
I tried to clean everyting buildout
On 17 July 2013 13:17, Nick Coghlan ncogh...@gmail.com wrote:
That said, the new metadata standard does deliberately include a few
pieces intended to make such things easier to define:
1. The extensions concept - using a structured data format like JSON
makes it much easier for platform
On 17 July 2013 19:43, Benedek Zoltan benzol...@yahoo.com wrote:
Hi,
I suspect the problem is with the changing infrastructure of
setuptools-distribute.
I'm happy to hear of this merge, thank you for all of you, who contributed
to these tools.
Am 15.07.2013 19:26, schrieb Donald Stufft:
Maybe this is a crazy idea, but would a windows only extension work?
.pye(executable) Then just associate .pye with the launcher. Python
won't see .pye as importable so there's no shadow issues.
pip.bat?
Thomas
On 17 July 2013 22:40, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 17 July 2013 13:17, Nick Coghlan ncogh...@gmail.com wrote:
That said, the new metadata standard does deliberately include a few
pieces intended to make such things easier to define:
1. The extensions concept - using a
On 17 July 2013 14:13, Thomas Heller thel...@ctypes.org wrote:
Am 15.07.2013 19:26, schrieb Donald Stufft:
Maybe this is a crazy idea, but would a windows only extension work?
.pye(executable) Then just associate .pye with the launcher. Python
won't see .pye as importable so there's no
On 17 July 2013 14:49, Thomas Heller thel...@ctypes.org wrote:
Yes, missed them. Sorry that I did not read enough of the discussion,
I just stumbled over some messages in this thread and .bat popped up in
my head.
No problem. It's probably useful to have a summary of the issues with bat
Am 17.07.2013 15:33, schrieb Paul Moore:
On 17 July 2013 14:13, Thomas Heller thel...@ctypes.org
mailto:thel...@ctypes.org wrote:
Am 15.07.2013 19:26, schrieb Donald Stufft:
Maybe this is a crazy idea, but would a windows only extension work?
.pye(executable) Then just
I'm going to be pushing an update to one of my projects to PyPI this week
and so I figured I could use this opportunity to help with patches to the
User Guide's packaging tutorial.
But to do that I wanted to ask what the current best practices are.
* Are we even close to suggesting wheels for
On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote:
I'm going to be pushing an update to one of my projects to PyPI this week
and so I figured I could use this opportunity to help with patches to the
User Guide's packaging tutorial.
But to do that I wanted to ask what the
On 17 Jul, 2013, at 17:46, Daniel Holth dho...@gmail.com wrote:
On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote:
I'm going to be pushing an update to one of my projects to PyPI this week
and so I figured I could use this opportunity to help with patches to the
User
On 17 July 2013 16:46, Daniel Holth dho...@gmail.com wrote:
* Are we saying use setuptools for everyone, or still only if you need
it
(asking since there is a stub about installing setuptools but the simple
example doesn't have a direct need for it ATM, but could use
find_packages()
and
On Wed, Jul 17, 2013 at 11:55 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 17 July 2013 16:46, Daniel Holth dho...@gmail.com wrote:
* Are we saying use setuptools for everyone, or still only if you need
it
(asking since there is a stub about installing setuptools but the simple
example
On 17 Jul, 2013, at 17:55, Paul Moore p.f.mo...@gmail.com wrote:
On 17 July 2013 16:46, Daniel Holth dho...@gmail.com wrote:
* Are we saying use setuptools for everyone, or still only if you need it
(asking since there is a stub about installing setuptools but the simple
example doesn't
On Wed, Jul 17, 2013 at 11:46 AM, Daniel Holth dho...@gmail.com wrote:
On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote:
I'm going to be pushing an update to one of my projects to PyPI this week
and so I figured I could use this opportunity to help with patches to the
On Jul 17, 2013, at 12:39 PM, Brett Cannon br...@python.org wrote:
On Wed, Jul 17, 2013 at 11:46 AM, Daniel Holth dho...@gmail.com wrote:
On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote:
I'm going to be pushing an update to one of my projects to PyPI this week
On Wed, Jul 17, 2013 at 12:45 PM, Donald Stufft don...@stufft.io wrote:
On Jul 17, 2013, at 12:39 PM, Brett Cannon br...@python.org wrote:
On Wed, Jul 17, 2013 at 11:46 AM, Daniel Holth dho...@gmail.com wrote:
On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote:
I'm
Brett Cannon brett at python.org writes:
Then I'm thoroughly confused since the Wheel PEP says in its rationale
that Python needs a package format that is easier to install than sdist.
That would suggest a wheel would work for a source distribution and replace
sdist zip/tar files. If wheels
On 17 July 2013 17:59, Brett Cannon br...@python.org wrote:
It is easier for the tooling to install and in general you'll want to use
them, but not everything supports Wheel and some people will want to build
their own wheels. Think of Wheel as a debian package and the sdist as the
source
On 07/17/2013 04:50 PM, Nick Coghlan wrote:
On 17 Jul 2013 18:17, holger krekel hol...@merlinux.eu
mailto:hol...@merlinux.eu wrote:
On Wed, Jul 17, 2013 at 07:48 +, Vinay Sajip wrote:
holger krekel holger at merlinux.eu http://merlinux.eu writes:
about existing schemes/efforts.
On Jul 17, 2013, at 11:46 AM, Daniel Holth wrote:
I'd like to see an ambitious person begin uploading wheels that have
no traditional sdist.
You're not getting rid of sdists are you?
Please note that without source distributions (preferably .tar.gz) your
package will never get distributed on a
On 17 July 2013 19:46, Barry Warsaw ba...@python.org wrote:
You're not getting rid of sdists are you?
There are as-yet unspecified plans for a sdist 2.0 format. It is expected
to fulfil the same role as current sdist, though, so no need to worry.
Please note that without source
On Jul 17, 2013, at 07:56 PM, Paul Moore wrote:
The long-term intent is to remove executable setup.py. When this happens,
definitely consumers (end users, Python tools like pip, and distro
packaging systems) will have some migration work to do. Keeping that
manageable will definitely be
On Jul 17, 2013, at 3:12 PM, Paul Moore p.f.mo...@gmail.com wrote:
The problem issue remaining is recognising when we need to do this. In terms
of code paths, pip install -U pip is no different from (for example) pip
install -U flask. But it needs to be handled specially just because it's
On 17 Jul, 2013, at 19:17, Trishank Karthik Kuppusamy t...@students.poly.edu
wrote:
To very briefly summarize our status without going into tangential details:
1. We previously found and reported on this mailing list that if we naively
assigned a key to every PyPI project, then the
On 17 July 2013 19:46, Barry Warsaw ba...@python.org wrote:
On Jul 17, 2013, at 11:46 AM, Daniel Holth wrote:
I'd like to see an ambitious person begin uploading wheels that have
no traditional sdist.
You're not getting rid of sdists are you?
Please note that without source distributions
On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote:
I imagined that distro packaging tools would end up using the wheel as
an intermediate format when building a deb from a source deb.
Do you mean, the distro would download the wheel or that it would build it
during the build step for the
On Jul 17, 2013, at 3:44 PM, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I meant the latter. The source deb would comprise the sdist (that may
or may not be traditional) and other distro files. The author of the
sdist designed it with the intention that it could be turned into a
wheel
On 17/07/2013 20:12, Paul Moore wrote:
On 17 July 2013 19:55, Steve Dower steve.do...@microsoft.com wrote:
I'm afraid exe files as wrappers are probably the only viable option.
The basic
reason is that the OS recognises exe files in all context, with no
special
configuration needed. This
On 17 July 2013 20:39, Barry Warsaw ba...@python.org wrote:
On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote:
I imagined that distro packaging tools would end up using the wheel as
an intermediate format when building a deb from a source deb.
Do you mean, the distro would download the wheel
On Wed, Jul 17, 2013 at 3:39 PM, Barry Warsaw ba...@python.org wrote:
On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote:
I imagined that distro packaging tools would end up using the wheel as
an intermediate format when building a deb from a source deb.
Do you mean, the distro would download
I'm afraid exe files as wrappers are probably the only viable option. The
basic
reason is that the OS recognises exe files in all context, with no special
configuration needed. This is not true of any other file type. So anything
else
will have corner cases that will give unexpected
In my opinion it is a good idea to embed, not just the *name* of the package
that your package depends on, but also the public key or public keys that your
package requires the depended-upon package to be signed by.
There was a time when wheel did this, using Ed25519 keys (which are nice and
On 17 July 2013 20:52, Daniel Holth dho...@gmail.com wrote:
On Wed, Jul 17, 2013 at 3:39 PM, Barry Warsaw ba...@python.org wrote:
On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote:
I imagined that distro packaging tools would end up using the wheel as
an intermediate format when building a deb
On Jul 17, 2013, at 3:58 PM, zooko zo...@zooko.com wrote:
In my opinion it is a good idea to embed, not just the *name* of the package
that your package depends on, but also the public key or public keys that your
package requires the depended-upon package to be signed by.
The problem with
On 17 July 2013 17:59, Brett Cannon br...@python.org wrote:
But it also sounds like that project providing wheel distributions is too
early to include in the User's Guide.
There are already many guides showing how to use distutils/setuptools
to do things the old way. There are also confused
The problem issue remaining is recognising when we need to do this. In terms
of
code paths, pip install -U pip is no different from (for example) pip install
-U
flask. But it needs to be handled specially just because it's pip. And it
*doesn't* need to be handled specially if it's python
Essentially, nothing changes from the user's standpoint or from the
standpoint of the package developer (except they sign their package).
The reason why we have multiple roles is to be robust against attacks in
case the main PyPI repo is hacked.
(Trishank can chime in with more complete /
Wheel provides a wheel keygen and wheel sign command and if you
set WHEEL_TOOL=/path/to/wheel then bdist_wheel will automatically sign
all the packages you create. Ideally wheel would sign every package,
reducing the problem from how do we force people to use PGP to how
do we derive value from
On 18 Jul 2013 01:46, Daniel Holth dho...@gmail.com wrote:
On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote:
I'm going to be pushing an update to one of my projects to PyPI this
week
and so I figured I could use this opportunity to help with patches to
the
User Guide's
On 18 Jul 2013 06:24, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 17 July 2013 17:59, Brett Cannon br...@python.org wrote:
But it also sounds like that project providing wheel distributions is
too
early to include in the User's Guide.
There are already many guides showing how to
On Wed, Jul 17, 2013 at 6:12 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 18 Jul 2013 06:24, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 17 July 2013 17:59, Brett Cannon br...@python.org wrote:
But it also sounds like that project providing wheel distributions is
too
On 18 Jul 2013 05:13, Paul Moore p.f.mo...@gmail.com wrote:
On 17 July 2013 19:55, Steve Dower steve.do...@microsoft.com wrote:
I'm afraid exe files as wrappers are probably the only viable option.
The basic
reason is that the OS recognises exe files in all context, with no
special
On 18 Jul 2013 08:18, Brett Cannon br...@python.org wrote:
On Wed, Jul 17, 2013 at 6:12 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 18 Jul 2013 06:24, Oscar Benjamin oscar.j.benja...@gmail.com
wrote:
On 17 July 2013 17:59, Brett Cannon br...@python.org wrote:
But it also sounds
Nick Coghlan ncoghlan at gmail.com writes:
It's good that distil exists as a proof of concept, but the ship has sailed
on the default language level installer: it will be pip.
I understand that it's your call as the packaging czar, but was there any
discussion about this before the decision
On Jul 17, 2013, at 6:30 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
It's good that distil exists as a proof of concept, but the ship has sailed
on the default language level installer: it will be pip.
I understand that it's your call as the
Donald Stufft donald at stufft.io writes:
I think bundling pip or bundling nothing is the only thing that makes
sense. There
actually *is* a PEP however it took a different approach that has been
(during the
discussions about it) decided that a different way would be less error
prone and
On 18 Jul 2013 08:31, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
It's good that distil exists as a proof of concept, but the ship has
sailed
on the default language level installer: it will be pip.
I understand that it's your call as the packaging
Nick Coghlan ncoghlan at gmail.com writes:
Technically the decision *hasn't* been made - there is, as yet, no
bundling PEP for me to consider for any installer, and I've decided not to
accept Richard's bootstrapping PEP due to the issues around delaying the
download to first use. I'd just
On 18 Jul 2013 09:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Technically the decision *hasn't* been made - there is, as yet, no
bundling PEP for me to consider for any installer, and I've decided not to
accept Richard's bootstrapping PEP due to
On 18 Jul 2013 09:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Technically the decision *hasn't* been made - there is, as yet, no
bundling PEP for me to consider for any installer, and I've decided not to
accept Richard's bootstrapping PEP due to
On Jul 17, 2013, at 7:36 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Just a few days
ago you were saying that python -m getpip would be good to have, then I
created a getpip module, and now AFAICT it hasn't even been looked at, while
people gear up to do shed-loads of work to bundle
Nick Coghlan ncoghlan at gmail.com writes:
No, my reservations are about delaying the installation of pip to first use
(or any time after the installation of Python). I don't care that much about
the distinction between bundling and install-time bootstrapping and would
appreciate a PEP that
Donald Stufft donald at stufft.io writes:
There was discussion around ``python -m getpip`` and the general thinking of
that
thread was that expecting users to type in an explicit command was adding
extra
steps into the process (and placing a dependency on the network connection
being
On Jul 17, 2013, at 8:03 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Leaving aside specialised corporate setups with no access to PyPI, any
installer is of very limited use without a reliable network connection. Most
of the people we're expecting to reach with these changes will have
On Jul 17, 2013, at 8:16 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Well, it's just one additional command to type in - it's really neither here
nor there as long as it's well documented.
There is already a getpip.py that's just not distributed with Python. So if
There
is only one
Nick Coghlan ncoghlan at gmail.com writes:
It's not about haters - it's about not causing additional pain for people
I used the term loosely in response to your comment about irritated and
angry people.
I'm talking about people who don't get mad, they just walk away. Or they
even stick
Donald Stufft donald at stufft.io writes:
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python
Well it doesn't work on Windows, which would be a reasonable objection to
using that specific approach.
But for various reasons many projects have decided that expecting
On Wed, Jul 17, 2013 at 8:16 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
There was discussion around ``python -m getpip`` and the general thinking of
that
thread was that expecting users to type in an explicit command was adding
extra
steps into
On Jul 17, 2013, at 8:38 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python
Well it doesn't work on Windows, which would be a reasonable objection to
using that specific
On Jul 17, 2013, at 8:40 PM, Daniel Holth dho...@gmail.com wrote:
I didn't realize the current option was about bundling pip itself
rather than including a simple bootstrap. I have favored the bootstrap
approach (being any intentionally limited installer that you would be
daft to use
My impression is this only holds for things signed directly by PyPI because
the developers have not registered a key. I think that developers who
register keys won't have this issue. Let's talk about this when you
return, but it's really projects / developers that will be stable in the
common
On 07/18/2013 03:24 AM, Ronald Oussoren wrote:
I'm trying to understand what this means for package maintainers. If I understand you
correctly maintainers would upload packages just like they do now, and packages are then
automaticly signed by the unstable role. Then some manual process by
On Jul 17, 2013, at 9:29 PM, Trishank Karthik Kuppusamy
t...@students.poly.edu wrote:
On 07/18/2013 03:24 AM, Ronald Oussoren wrote:
I'm trying to understand what this means for package maintainers. If I
understand you correctly maintainers would upload packages just like they do
now, and
On 07/18/2013 09:34 AM, Justin Cappos wrote:
My impression is this only holds for things signed directly by PyPI
because the developers have not registered a key. I think that
developers who register keys won't have this issue. Let's talk about
this when you return, but it's really projects
If there is not a compromise of PyPI, then all updates happen essentially
instantly.
Developers that do not sign packages and so PyPI signs them, may have their
newest packages remain unavailable for a period of up to 3 months *if there
is a compromise of PyPI*.
Thanks,
Justin
On Wed, Jul 17,
On Jul 17, 2013, at 9:52 PM, Justin Cappos jcap...@poly.edu wrote:
If there is not a compromise of PyPI, then all updates happen essentially
instantly.
Developers that do not sign packages and so PyPI signs them, may have their
newest packages remain unavailable for a period of up to 3
Sure.
The stable key is kept offline (not on PyPI). It knows who the
developers for projects are and delegates trust to them. So Django (for
example), has its key signed by this offline key.
The bleeding-edge key is kept online on PyPI. It is used to sign
project keys for projects newer
On 18 July 2013 10:33, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
More importantly, it doesn't seem like the PEP process has been followed, as
other proposed alternatives (I mean the approach of python -m getpip, as
well as my specific suggested
On 18 July 2013 12:06, Justin Cappos jcap...@poly.edu wrote:
Sorry for any confusion about this. We will provide a bunch of other
information soon (should we do this as a PEP?) along with example metadata
and working code. We definitely appreciate any feedback.
It's probably too early for
Okay, we'll get this together once Trishank returns and we've had a chance
to write up the latest.
Justin
On Wed, Jul 17, 2013 at 11:52 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 18 July 2013 12:06, Justin Cappos jcap...@poly.edu wrote:
Sorry for any confusion about this. We will
But it also sounds like that project providing wheel distributions is too
early to include in the User's Guide.
My intention is for the user guide to cover building and installing wheels.
Hi,
Also, just noticed that 0.7.3 is available as .zip, but not as .tar.gz
like the others are.
Liam
--
Liam Kirsher
PGP: http://liam.numenet.com/pgp/
___
Distutils-SIG maillist - Distutils-SIG@python.org
89 matches
Mail list logo
