From p.f.moore at gmail.com  Mon Apr  2 09:21:26 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 2 Apr 2018 14:21:26 +0100
Subject: [Distutils] Beta release of pip version 10
Message-ID: <CACac1F_nGyDQ-MCuqiewQiMRsRL1Z4H8BNwq2j4Os+Gk-g1BKQ@mail.gmail.com>

Unfortunately there was an issue in one of the release files (the CA
Certificate bundle contained Windows line endings instead of Unix line
endings) which caused crashes on older versions of MacOS. As a result
we have just released 10.0.0b2, fixing this issue.

Anyone on older MacOS versions who have had problems with the 10.0.0b1
release should upgrade to 10.0.0b2.

Thanks,
Paul

On 31 March 2018 at 12:11, Paul Moore <p.f.moore at gmail.com> wrote:
> On behalf of the PyPA, I am pleased to announce that a beta release
> 10.0.0b1 of pip has just been released for testing by the community.
> We're planning on a final release in 2 weeks' time, over the weekend
> of 14/15 April.
>
> To install pip 10.0.0.b1, you can run
>
>     python -m pip install --upgrade --pre pip
>
> (obviously, you should not do this in a production environment!)
>
> We would be grateful for all testing that users could do, to ensure
> that when pip 10 is released it's as solid as we can make it.
>
> Highlights of the new release:
>
> * Python 2.6 is no longer supported - if you need pip on Python 2.6,
> you should stay on pip 9, which is the last version to support Python
> 2.6.
> * Support for PEP 518, which allows projects to specify what packages
> they require in order to build from source. (PEP 518 support is
> currently limited, with full support coming in future versions - see
> the documentation for details).
> * Significant improvements in Unicode handling for non-ASCII locales on Windows.
> * A new "pip config" command.
> * The default upgrade strategy has become "only-if-needed"
> * Many bug fixes and minor improvements.
>
> In addition, the previously announced reorganisation of pip's
> internals has now taken place. Unless you are the author of code that
> imports the pip module (or a user of such code), this change will not
> affect you. If you are, please report the issue to the author of the
> affected code (refer them to
> https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html
> for the details of the announcement).
>
> Please note that there is a minor issue with the NEWS file for this
> release - the new features in 10.0.0b1 are reported as being for
> "9.0.3 (2018-03-31)".
>
> If you discover any bugs while testing the new release, please report
> them at https://github.com/pypa/pip/issues.
>
> Thanks to everyone who put so much effort into the new release. Many
> of the contributions came from community members, whether in the form
> of code, participation in design discussions, or bug reports. The pip
> development team is extremely grateful to everyone in the community
> for their contributions.
>
> Thanks,
> Paul

From trishank.kuppusamy at datadoghq.com  Mon Apr  2 12:45:17 2018
From: trishank.kuppusamy at datadoghq.com (Trishank Kuppusamy)
Date: Mon, 2 Apr 2018 12:45:17 -0400
Subject: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was:
 PEP 571: Any further manylinux2010 concerns or questions?
In-Reply-To: <CADiSq7cGO5rA1SmRMKaoxNuA8QQLZ-rdBPKu71ahnQrTG=orLw@mail.gmail.com>
References: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
 <CAEd-exNtHFoGKjLSFPwF_fSF3QcCHCtJsjwgh0H=QXX5rfB1fQ@mail.gmail.com>
 <CAP1=2W6cgk=inxJ2dzrhC3TVdXAuZdtr6b0QCM-dbECH5VMuHw@mail.gmail.com>
 <CADiSq7cGO5rA1SmRMKaoxNuA8QQLZ-rdBPKu71ahnQrTG=orLw@mail.gmail.com>
Message-ID: <CAEd-exNrCTXnF9OnGV46kB8B-uLf6JuQfoK57yU4xOocP+xSdw@mail.gmail.com>

Hi Brett, Donald, and Nick,

Thanks for your replies!

On Sat, Mar 31, 2018 at 11:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

>
> The main reason PyPI doesn't currently support distro specific wheels is
> because there isn't a compatibility tagging spec for them that's reasonable
> to use on a public index server - they currently end up being tagged as
> generic "linux" wheels. You can live with that on a private index server
> like the one that https://galaxyproject.org/ runs, but it would be
> incredibly confusing on PyPI.
>
> As far as I know, https://mail.python.org/pipermail/distutils-sig/2015-
> July/026617.html is still the most complete write-up we have of a
> potential way to fix that, which is to:
>
> 1. extend the default Linux platform tag to include the ID and VERSION_ID
> fields from /etc/os-release (credit to Galaxy Project's Nate Coraor for
> that core concept)
> 2. define a config file under /etc/python/ that distros can use to change
> both the build tag (e.g. allowing CentOS users to emit RHEL compatible
> wheels, or Ubuntu users to emit Debian compatible ones), and a list of
> binary compatible distro tags (e.g. allowing CentOS to consume RHEL tagged
> wheels, Ubuntu to consume Debian tagged wheels, and other musl based
> distros to consume Alpine tagged wheels)
> 3. define an equivalent per-virtualenv file to override the settings from
> (2)
> 4. update pip/setuptools/twine/warehouse/etc to account for the new
> compatibility tag variant
>
> One useful aspect here is that older clients will just ignored the new
> tags as "not a match", which means there shouldn't be any significant
> backwards compatibility hurdles.
>
> Honestly, I think the main benefit of heading down this road will be to
> allow folks to cache their custom wheel builds more effectively, so I'm not
> especially worried about making it generic (beyond the platform level
> config file suggested above).
>
> That said, if there were to be a significant growth in non-manylinux Linux
> wheels on PyPI, I'd expect them to be for the official Docker Inc base
> Python images, which are Alpine based, and hence can't use the glibc-based
> manylinux binaries.
>

I think this is a good idea, especially given that manylinux1 and
manylinux2010 wheels won't work on the official Docker image for Python.
What does everyone else think?

If we wanted to contribute towards this effort, how can the community help,
Nick?

Thanks,
Trishank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180402/044579d1/attachment.html>

From p.f.moore at gmail.com  Mon Apr  2 13:08:00 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 2 Apr 2018 18:08:00 +0100
Subject: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was:
 PEP 571: Any further manylinux2010 concerns or questions?
In-Reply-To: <CAEd-exNrCTXnF9OnGV46kB8B-uLf6JuQfoK57yU4xOocP+xSdw@mail.gmail.com>
References: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
 <CAEd-exNtHFoGKjLSFPwF_fSF3QcCHCtJsjwgh0H=QXX5rfB1fQ@mail.gmail.com>
 <CAP1=2W6cgk=inxJ2dzrhC3TVdXAuZdtr6b0QCM-dbECH5VMuHw@mail.gmail.com>
 <CADiSq7cGO5rA1SmRMKaoxNuA8QQLZ-rdBPKu71ahnQrTG=orLw@mail.gmail.com>
 <CAEd-exNrCTXnF9OnGV46kB8B-uLf6JuQfoK57yU4xOocP+xSdw@mail.gmail.com>
Message-ID: <CACac1F9J=KtrnBBecmAc0pr82z8Vs81c24sTTwspsAB0MbHWJA@mail.gmail.com>

On 2 April 2018 at 17:45, Trishank Kuppusamy
<trishank.kuppusamy at datadoghq.com> wrote:
>> That said, if there were to be a significant growth in non-manylinux Linux
>> wheels on PyPI, I'd expect them to be for the official Docker Inc base
>> Python images, which are Alpine based, and hence can't use the glibc-based
>> manylinux binaries.
>
> I think this is a good idea, especially given that manylinux1 and
> manylinux2010 wheels won't work on the official Docker image for Python.
> What does everyone else think?

My (mostly uninformed...) opinion is that having a mechanism to
publish wheels for alternative compatibility classes (I hesitate to
say "user defined" or "adhoc", because it implies too little
structure, but I'm thinking in terms of something similar to
manylinux, but without the need for a formal standards process) would
be useful, because it would allow people to handle emerging standards
like Alpine Linux for Docker, without going through a standardisation
process, a pip/pypi release cycle, etc. I've no feel for how likely
Alpine Linux is to still be as important as it currently is 12 months
from now (maybe Docker will switch to an alternative base, who knows?)
but we should be giving the community a means to react to such trends
in a timely manner.

Paul

From vinays75 at gmail.com  Mon Apr  2 15:39:42 2018
From: vinays75 at gmail.com (Vinay Sharma)
Date: Mon, 2 Apr 2018 12:39:42 -0700
Subject: [Distutils] Facing a strange issue while uploading my package using
 devpi
Message-ID: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>

I am not sure if this is the right forum to ask this question. If it is not
then please ignore this email and point me to the right forum (if anyone
knows).

I have a Jenkins Job to build my Python Package. At the end of this Jenkins
Job there are bunch of commands to upload the recently build Python Package
to devpi server.

When I am trying to upload my application distribution using following
command "devpi upload" in Jenkins I am getting an the following error :-

my_application.tar.gz: does not contain PKGINFO, skipping


I have checked everything and everything looks to be good like I have the
proper README.rst etc from which the proper PKG-INFO file should be
generated.

Any pointers would be a great help...

Regards
-Vinay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180402/70812d09/attachment.html>

From di at di.codes  Mon Apr  2 16:43:43 2018
From: di at di.codes (Dustin Ingram)
Date: Mon, 2 Apr 2018 15:43:43 -0500
Subject: [Distutils] Facing a strange issue while uploading my package
 using devpi
In-Reply-To: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
References: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
Message-ID: <CACHw_mRMr0KD2TsR1gwgHBUrp8bs33TdJT3vGKuDCMeS4rkTTQ@mail.gmail.com>

Some more information about the environment you built your
distribution in would be helpful.

The `PKG-INFO` file is not derived from your README, if you un-tar the
source distribution, is there a file named `PKG-INFO` in the top-level
directory?

What's the result of running using the `pkginfo` project [0] to
extract the metadata?

```
import pkginfo
print(pkginfo.get_metadata('my_application.tar.gz'))
```

[0] https://pypi.org/project/pkginfo/

D.

On Mon, Apr 2, 2018 at 2:39 PM, Vinay Sharma <vinays75 at gmail.com> wrote:
> I am not sure if this is the right forum to ask this question. If it is not
> then please ignore this email and point me to the right forum (if anyone
> knows).
>
> I have a Jenkins Job to build my Python Package. At the end of this Jenkins
> Job there are bunch of commands to upload the recently build Python Package
> to devpi server.
>
> When I am trying to upload my application distribution using following
> command "devpi upload" in Jenkins I am getting an the following error :-
>
> my_application.tar.gz: does not contain PKGINFO, skipping
>
>
> I have checked everything and everything looks to be good like I have the
> proper README.rst etc from which the proper PKG-INFO file should be
> generated.
>
> Any pointers would be a great help...
>
> Regards
> -Vinay
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>

From jwodder at gmail.com  Mon Apr  2 16:54:15 2018
From: jwodder at gmail.com (John Thorvald Wodder II)
Date: Mon, 2 Apr 2018 16:54:15 -0400
Subject: [Distutils] Facing a strange issue while uploading my package
 using devpi
In-Reply-To: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
References: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
Message-ID: <7F5F3FA0-6BE0-404B-8225-D6AAAA337AE3@gmail.com>

> On 2018 Apr 2, at 15:39, Vinay Sharma <vinays75 at gmail.com> wrote:
> 
> I am not sure if this is the right forum to ask this question. If it is not then please ignore this email and point me to the right forum (if anyone knows).

This might be a Python packaging problem, or it might be a devpi problem.  We won't know until it's solved; such is the nature of problems.

> I have a Jenkins Job to build my Python Package. At the end of this Jenkins Job there are bunch of commands to upload the recently build Python Package to devpi server. 
> 
> When I am trying to upload my application distribution using following command "devpi upload" in Jenkins I am getting an the following error :-
> 
> my_application.tar.gz: does not contain PKGINFO, skipping

Is the "application distribution" that you're trying to upload actually an sdist (source distribution) or just a normal tarball?  The only kind of tarballs that Python package indices deal with are sdists, which are made with either `python setup.py sdist` (if you're using setuptools) or `flit build --format=sdist` (if you're using flit).

> I have checked everything and everything looks to be good like I have the proper README.rst etc from which the proper PKG-INFO file should be generated.

*Is* the PKG-INFO file generated and included in the tarball, though?


From sh at changeset.nyc  Mon Apr  2 16:48:31 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Mon, 2 Apr 2018 16:48:31 -0400
Subject: [Distutils] Mac users, upgrade to pip 9.0.3 (due to TLS deprecation)
Message-ID: <1e2ffa22-8e4e-c35e-45fd-cb4067bd4728@changeset.nyc>

Mac users who use pip and PyPI:

If you are running macOS/OS X version 10.12 or older, then you ought to
upgrade to the latest pip (9.0.3) to connect to the Python Package Index
securely:

    curl https://bootstrap.pypa.io/get-pip.py | python

and we recommend you do that by April 8th.

Pip 9.0.3 supports TLSv1.2 when running under system Python on macOS <
10.13. Official release notes: https://pip.pypa.io/en/stable/news/

Context:

As PSF blogged last year
https://pyfound.blogspot.com/2017/01/time-to-upgrade-your-python-tls-v12.html
, on June 30, 2018, Python.org sites are going to entirely stop
supporting TLS versions 1.0 and 1.1, because our CDN provider is
deprecating support for those versions.

We are launching the new PyPI (in beta at https://pypi.org) this month
and replacing the legacy PyPI (https://pypi.python.org). Here's the beta
announcement for the new PyPI:
https://pyfound.blogspot.com/2018/03/warehouse-all-new-pypi-is-now-in-beta.html

Warehouse, the codebase for the new PyPI, does not support TLS 1.0 or 1.1.

As of late March, the Python Package Index has started doing brownouts
of the deprecated TLS versions. For some portion of each hour, anyone
attempting to access PyPI with TLSv1.0 or TLSv1.1 will get a 403
response with an informative error. We are ramping up the amount of time
the endpoint is down for the deprecated TLS versions, and plan to make
the endpoint 100% unavailable (for the deprecated TLS versions) on and
after April 8th, prior to the final deadline. That gives us a few months
where, someone tries to "pip install", we can give a good error message
-- once June 30th hits, it will just be an uninformative OpenSSL error.

More info:

* https://github.com/pypa/warehouse/issues/3293
* https://github.com/pypa/warehouse/issues/3411
* https://status.python.org/incidents/btjtz01lzp88

If you have problems accessing PyPI, upgrading pip, etc., please file an
issue at https://github.com/pypa/packaging-problems/issues/ and we'll
help figure it out.

Thank you. Please publicize this. (I'm about to cross-post this to
python-list/comp.lang.python.)

-- 
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
https://changeset.nyc

From vinays75 at gmail.com  Mon Apr  2 19:38:09 2018
From: vinays75 at gmail.com (Vinay Sharma)
Date: Mon, 2 Apr 2018 16:38:09 -0700
Subject: [Distutils] Facing a strange issue while uploading my package
 using devpi
In-Reply-To: <7F5F3FA0-6BE0-404B-8225-D6AAAA337AE3@gmail.com>
References: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
 <7F5F3FA0-6BE0-404B-8225-D6AAAA337AE3@gmail.com>
Message-ID: <CAAkvi+U1C5KjnoHFmVbQw9eBRY-p2m5ZTkb5taf1yGBTWiJJFw@mail.gmail.com>

Here are the answers to your questions and some new insights which I found
today :-
a) This problem happens during the Jenkins Job only. I tried the build
steps manually on my local code base (which were exactly same as my Jenkins
Job) and it uploaded the distribution file perfectly.
b) The "application distribution" that I am trying to upload is a sdist
file. Till few days back this Jenkins job used to run fine and upload the
"application package perfectly" but suddenly from last week started getting
this 'PKGINFO' missing error there has not been any change related to
application packaging.
c) Following is the result of the steps which Dustin suggested (This tar
file was generated by Jenkins Job)

*******
import pkginfo

print(pkginfo.get_metadata('/users/user1/my_application.tar.gz'))

******

output <pkginfo.sdist.SDist object at 0x7f8cb001b390>


d) After untar of my_application.tar.gz which was build using Jenkins Job I
see the PKG-INFO file at the root folder.


One small point (not sure if this is even valid or not). The Error which I
get from Jenkins is this "my_application.tar.gz: does not contain PKGINFO,
skipping" , if you look at what it complains is "PKGINFO" note it does not
have "-" between the word "PKG" and "INFO" can this be a problem? But again
there has been no change in the application packaging but you never know :-)


Regards

-Vinay

On Mon, Apr 2, 2018 at 1:54 PM, John Thorvald Wodder II <jwodder at gmail.com>
wrote:

> > On 2018 Apr 2, at 15:39, Vinay Sharma <vinays75 at gmail.com> wrote:
> >
> > I am not sure if this is the right forum to ask this question. If it is
> not then please ignore this email and point me to the right forum (if
> anyone knows).
>
> This might be a Python packaging problem, or it might be a devpi problem.
> We won't know until it's solved; such is the nature of problems.
>
> > I have a Jenkins Job to build my Python Package. At the end of this
> Jenkins Job there are bunch of commands to upload the recently build Python
> Package to devpi server.
> >
> > When I am trying to upload my application distribution using following
> command "devpi upload" in Jenkins I am getting an the following error :-
> >
> > my_application.tar.gz: does not contain PKGINFO, skipping
>
> Is the "application distribution" that you're trying to upload actually an
> sdist (source distribution) or just a normal tarball?  The only kind of
> tarballs that Python package indices deal with are sdists, which are made
> with either `python setup.py sdist` (if you're using setuptools) or `flit
> build --format=sdist` (if you're using flit).
>
> > I have checked everything and everything looks to be good like I have
> the proper README.rst etc from which the proper PKG-INFO file should be
> generated.
>
> *Is* the PKG-INFO file generated and included in the tarball, though?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180402/e362a96b/attachment-0001.html>

From drsalists at gmail.com  Mon Apr  2 22:54:41 2018
From: drsalists at gmail.com (Dan Stromberg)
Date: Mon, 2 Apr 2018 19:54:41 -0700
Subject: [Distutils] Facing a strange issue while uploading my package
 using devpi
In-Reply-To: <CAAkvi+U1C5KjnoHFmVbQw9eBRY-p2m5ZTkb5taf1yGBTWiJJFw@mail.gmail.com>
References: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
 <7F5F3FA0-6BE0-404B-8225-D6AAAA337AE3@gmail.com>
 <CAAkvi+U1C5KjnoHFmVbQw9eBRY-p2m5ZTkb5taf1yGBTWiJJFw@mail.gmail.com>
Message-ID: <CAGGBd_qLPU0TVmcbZRZyp-s=ayJ2CQOMaCvMKSY_EuaW_P_ZbA@mail.gmail.com>

On Mon, Apr 2, 2018 at 4:38 PM, Vinay Sharma <vinays75 at gmail.com> wrote:
> Here are the answers to your questions and some new insights which I found
> today :-
> a) This problem happens during the Jenkins Job only. I tried the build steps
> manually on my local code base (which were exactly same as my Jenkins Job)
> and it uploaded the distribution file perfectly.

Often when the same commands produce different results under 2
different accounts on the same computer, it's because of an
environment variable difference:

I wrote this years ago to help track down env var issues:
http://stromberg.dnsalias.org/~strombrg/env-search.html

HTH

From ncoghlan at gmail.com  Tue Apr  3 07:59:36 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 3 Apr 2018 21:59:36 +1000
Subject: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was:
 PEP 571: Any further manylinux2010 concerns or questions?
In-Reply-To: <CAEd-exNrCTXnF9OnGV46kB8B-uLf6JuQfoK57yU4xOocP+xSdw@mail.gmail.com>
References: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
 <CAEd-exNtHFoGKjLSFPwF_fSF3QcCHCtJsjwgh0H=QXX5rfB1fQ@mail.gmail.com>
 <CAP1=2W6cgk=inxJ2dzrhC3TVdXAuZdtr6b0QCM-dbECH5VMuHw@mail.gmail.com>
 <CADiSq7cGO5rA1SmRMKaoxNuA8QQLZ-rdBPKu71ahnQrTG=orLw@mail.gmail.com>
 <CAEd-exNrCTXnF9OnGV46kB8B-uLf6JuQfoK57yU4xOocP+xSdw@mail.gmail.com>
Message-ID: <CADiSq7dmMALe9zy3mgxChh3VOAh0P9OOdh05Bf3-MnL+J9OwUQ@mail.gmail.com>

On 3 April 2018 at 02:45, Trishank Kuppusamy
<trishank.kuppusamy at datadoghq.com> wrote:
> On Sat, Mar 31, 2018 at 11:06 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The main reason PyPI doesn't currently support distro specific wheels is
>> because there isn't a compatibility tagging spec for them that's reasonable
>> to use on a public index server - they currently end up being tagged as
>> generic "linux" wheels. You can live with that on a private index server
>> like the one that https://galaxyproject.org/ runs, but it would be
>> incredibly confusing on PyPI.
>>
>> As far as I know,
>> https://mail.python.org/pipermail/distutils-sig/2015-July/026617.html is
>> still the most complete write-up we have of a potential way to fix that,
>> which is to:
>>
>> 1. extend the default Linux platform tag to include the ID and VERSION_ID
>> fields from /etc/os-release (credit to Galaxy Project's Nate Coraor for that
>> core concept)
>> 2. define a config file under /etc/python/ that distros can use to change
>> both the build tag (e.g. allowing CentOS users to emit RHEL compatible
>> wheels, or Ubuntu users to emit Debian compatible ones), and a list of
>> binary compatible distro tags (e.g. allowing CentOS to consume RHEL tagged
>> wheels, Ubuntu to consume Debian tagged wheels, and other musl based distros
>> to consume Alpine tagged wheels)
>> 3. define an equivalent per-virtualenv file to override the settings from
>> (2)
>> 4. update pip/setuptools/twine/warehouse/etc to account for the new
>> compatibility tag variant

[snip]

> If we wanted to contribute towards this effort, how can the community help,
> Nick?

At the specification level, we'll need an update to PEP 425 that's
comparable to Dustin's PEP 566 for the core metadata (which both
defined metadata 2.1, and made
https://packaging.python.org/specifications/core-metadata/ the stable
reference URL for the latest version of the metadata spec).

I'd like to see us do the same thing for platform compatibility tags:
have https://packaging.python.org/specifications/platform-compatibility-tags/
define the format, and use the PEP process to make changes to that
living spec.

While the primary motivating use case is distro-specific Linux wheels,
we should at least consider the possibility of defining the new
optional fields in compatibility tags in such a way that they could
also be used for ABI compatibility levels in more centrally controlled
platforms (i.e. Windows, macOS, iOS, Android), or to tag an expected
deployment environment (e.g. letting the Galaxy Project folks mark all
their internal wheels as "galaxyproject", and then configure their
deployment environments to only accept wheels tagged that way).

Such a spec update would cover points 1->3 above.

At the implementation level, I don't have any great insight on how you
might best go about pursuing that, but I suspect factoring out some
useful helper functions into the low level `packaging` library may
make sense (I believe Vinay Sajip's `distlib` already has some helpers
along these lines that would potentially require updates). At a
minimum, to be useful:

* either setuptools+bdist_wheel need to be able to produce wheels with
the more detailed tags, or else there has be a suitable wheel renaming
utility available (akin to `auditwheel repair`)
* twine needs to be able to upload wheels with the more detailed tags
* warehouse needs to be able to accept uploads with the more detailed tags

(For that last point, I'd personally prefer it to be a project level
setting to opt-in to allowing uploads with the more detailed tags,
such that the default behaviour is to reject them, and provide an
opportunity for us to nudge folks towards manylinux wheels)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From sh at changeset.nyc  Tue Apr  3 10:44:14 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 3 Apr 2018 10:44:14 -0400
Subject: [Distutils] IRC/Twitter livechats about Warehouse today & Thursday
In-Reply-To: <759b103e-6452-0f5d-1013-7e51a07a6dad@changeset.nyc>
References: <759b103e-6452-0f5d-1013-7e51a07a6dad@changeset.nyc>
Message-ID: <9d54feee-7888-387b-9708-6c0ea438fedd@changeset.nyc>

The next one starts in ~16 minutes. Links, etc. at
https://pyfound.blogspot.com/2018/03/warehouse-all-new-pypi-is-now-in-beta.html#livechat
.

-Sumana

On 03/26/2018 05:13 PM, Sumana Harihareswara wrote:
> Warehouse developers will be in IRC, in #pypa-dev on Freenode, and on
> Twitter (hashtag: #newpypi), available to talk about problems you run
> into, or about how to hack on Warehouse, for four livechats over the
> next few weeks:
> 
> 
> 1. Tuesday, March 27th, 9am-10am PDT, noon-1pm EDT, 18:00-19:00 CEST,
> 9:30pm-10:30pm India, 16:00-17:00 UTC
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Warehouse/PyPI+beta+chat&iso=20180327T16&p1=:&ah=1
> 
> 
> 2. Friday, March 30th, 10-11am EDT, 16:00-17:00 CEST, 7:30pm-8:30pm
> India, 14:00-15:00 UTC
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Warehouse/PyPI+beta+live+chat&iso=20180330T14&p1=1440&ah=1
> 
> 
> 3.  Tuesday, April 3rd, 8am-9am PDT, 11am-noon EDT, 17:00-18:00 CEST,
> 8:30pm-9:30pm India, 15:00-16:00 UTC
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Warehouse/PyPI+beta+livechat&iso=20180403T10&p1=24&ah=1
> 
> 
> 4. Thursday, April 5th, 5pm-6pm PDT, 8pm-9pm EDT, (April 5th) 8am-9am
> Manila, (April 5th) 10am-11am Melbourne, (April 5th) 0:00-1:00 UTC
> https://www.timeanddate.com/worldclock/fixedtime.html?p1=24&iso=20180405T19&msg=Warehouse/PyPI%20beta%20livechat&ah=1&low=4
> 
> 
> Feel free to drop in! (By participating, you agree to abide by the PyPA
> Code of Conduct: https://www.pypa.io/en/latest/code-of-conduct/ .)
> 

From trishank.kuppusamy at datadoghq.com  Tue Apr  3 10:49:05 2018
From: trishank.kuppusamy at datadoghq.com (Trishank Kuppusamy)
Date: Tue, 3 Apr 2018 10:49:05 -0400
Subject: [Distutils] Any thoughts on supporting e.g. Alpine Linux? (was:
 PEP 571: Any further manylinux2010 concerns or questions?
In-Reply-To: <CADiSq7dmMALe9zy3mgxChh3VOAh0P9OOdh05Bf3-MnL+J9OwUQ@mail.gmail.com>
References: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
 <CAEd-exNtHFoGKjLSFPwF_fSF3QcCHCtJsjwgh0H=QXX5rfB1fQ@mail.gmail.com>
 <CAP1=2W6cgk=inxJ2dzrhC3TVdXAuZdtr6b0QCM-dbECH5VMuHw@mail.gmail.com>
 <CADiSq7cGO5rA1SmRMKaoxNuA8QQLZ-rdBPKu71ahnQrTG=orLw@mail.gmail.com>
 <CAEd-exNrCTXnF9OnGV46kB8B-uLf6JuQfoK57yU4xOocP+xSdw@mail.gmail.com>
 <CADiSq7dmMALe9zy3mgxChh3VOAh0P9OOdh05Bf3-MnL+J9OwUQ@mail.gmail.com>
Message-ID: <CAEd-exMXhWU=aS_YQZhizm9WOozPq0MDQjD1jXDAN+e2Lfh1gw@mail.gmail.com>

Hello Nick,

On Tue, Apr 3, 2018 at 7:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

>
> At the specification level, we'll need an update to PEP 425 that's
> comparable to Dustin's PEP 566 for the core metadata (which both
> defined metadata 2.1, and made
> https://packaging.python.org/specifications/core-metadata/ the stable
> reference URL for the latest version of the metadata spec).
>
> I'd like to see us do the same thing for platform compatibility tags:
> have https://packaging.python.org/specifications/platform-
> compatibility-tags/
> define the format, and use the PEP process to make changes to that
> living spec.
>
> While the primary motivating use case is distro-specific Linux wheels,
> we should at least consider the possibility of defining the new
> optional fields in compatibility tags in such a way that they could
> also be used for ABI compatibility levels in more centrally controlled
> platforms (i.e. Windows, macOS, iOS, Android), or to tag an expected
> deployment environment (e.g. letting the Galaxy Project folks mark all
> their internal wheels as "galaxyproject", and then configure their
> deployment environments to only accept wheels tagged that way).
>
> Such a spec update would cover points 1->3 above.
>
> At the implementation level, I don't have any great insight on how you
> might best go about pursuing that, but I suspect factoring out some
> useful helper functions into the low level `packaging` library may
> make sense (I believe Vinay Sajip's `distlib` already has some helpers
> along these lines that would potentially require updates). At a
> minimum, to be useful:
>
> * either setuptools+bdist_wheel need to be able to produce wheels with
> the more detailed tags, or else there has be a suitable wheel renaming
> utility available (akin to `auditwheel repair`)
> * twine needs to be able to upload wheels with the more detailed tags
> * warehouse needs to be able to accept uploads with the more detailed tags
>
> (For that last point, I'd personally prefer it to be a project level
> setting to opt-in to allowing uploads with the more detailed tags,
> such that the default behaviour is to reject them, and provide an
> opportunity for us to nudge folks towards manylinux wheels)


Sounds good. I'll take a stab at updating the PEP, and see. Can't make any
promises as to a timeline, but I'll get back when (and if) I have a draft!

Regards,
Trishank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180403/1b29778f/attachment-0001.html>

From sh at changeset.nyc  Tue Apr  3 22:29:30 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 03 Apr 2018 22:29:30 -0400
Subject: [Distutils] PyPI/Warehouse update: new advice & launch,
 shutdown dates
Message-ID: <1522808970.1281874.1325630552.6B0A40EC@webmail.messagingengine.com>

Big news: we have a schedule for April, and we're advising less-
intensive API users to switch to hitting pypi.org.
April plans[1] (decided this in yesterday's Warehouse core developers'
meeting[2]):
1. Sunday April 8th: TLS 1.0/1.1 removal[3]
2. Monday April 9th: publicize pypi.org launch date (especially to
   package maintainers and PyPI sponsors)3. Monday April 16: launch/redirect (API and browser traffic redirected
   to Warehouse)4. Monday April 30: shut down legacy PyPI

And today in IRC we decided: If your site/service used to link or
upload to pypi.python.org, you should possibly start using pypi.org
instead[4]. Now.
Specifically:

If you have an automated tool that hits pypi.python.org less often than
once a second, and/or you are fine with small service interruptions
during the beta, then you should go ahead and start using pypi.org
now[5], and subscribe to the PyPI announcement list (low-traffic) for
further announcements[6].
If you run a mission-critical automated production setup, or an
automated tool that hits pypi.python.org with 1+ requests/second, then
you should not explicitly point to pypi.org yet, but you should test and
prepare to switch[7]. You should also watch our status page[8], since
we?re occasionally redirecting portions of that traffic in load tests
that we announce on the status page. Subscribe to the PyPI announcement
list (low-traffic)[9] to find out when you should switch permanently.

Now the more general work update. It's huge because we've been doing so
much, our volunteers are prolific, and I truncated last week's report so
this is a double issue and I will understand if many of you say "TL;DR".
We have 13 open issues till we can launch and redirect pypi.python.org
traffic to Warehouse, and then we have 9 open issues till we can shut
down legacy PyPI (overview[10]). We've been whittling away at that pile,
and fixing other issues as they come up, while responding to new bug
reports (and praise) over the last few weeks (a bit slower because of
some (planned) team absences).
Some improvements from the last two weeks from the MOSS-funded team:

 * our API docs are more accurate[11] and include policies[12]
 *  our "browse" page has default text and suggested searches[13], and
    adjusts to page width[14]
 * prep in case we ever need to briefly turn the site read-only during
   maintenance[15]
 * project pages point you to sources for project stats[16] and release
   notifications[17]
 *  notifications (banners) are dismissable[18]
 * performance and indexing/caching-related improvements, e.g., purging
   projects & user pages when someone's role changes[19], updating the
   trending projects[20], and updating the search index more often[21]
 * activity journal item order is more consistent and deterministic[22]
 * a project's last serial ID is available via Simple & JSON APIs[23]
Also, Nicole did a bunch of cross-browser testing[24], Ernest worked on
a docs proxy[25] and updated parts of legacy PyPI to point to
Warehouse[26], Dustin fixed issues affecting twine --skip-existing[27]
and a classifier error[28], and I improved developer docs[29] and
classifier order[30]. And Warehouse founder and continuing contributor
Donald Stufft moved email handling into a service[31], improved
performance[32], and removed TLS 1.0/1.1 support[33].
It's deeply important to me to spread the word about the beta, so as
many of our friends, neighbors, and colleagues as possible can try
Warehouse before the big switch, and so we can know about potential
showstoppers as early as possible. So we've held multiple virtual office
hours (IRC logs from today's chat[34]), and we've posted to Python-
specific spaces like the Python Insider blog[35] and python-announce[36]
and debian-python[37], but we've also done some work to get the word out
to programmers who don't particularly pay attention to English-language
Python-specific news. We found volunteers to translate and post the
announcement a little (Brazilian Portugese[38], Polish[39]), and reached
out to (for instance) Software & Data Carpentry[40], NumFOCUS[41], The
Changelog[42], FLOSS Weekly[43] (who'll interview Ernest and Dustin on
May 2nd), and Public Lab[44]. I have a giant checklist and I have been
crossing many things off. It's very satisfying.
I tried out combining our IRC livechats with a Twitter hashtag,
#newpypi, and have gotten approximately zero questions through that so
far. Regardless: enjoy some screenshots!  [45]
And overlapping with the beta rollout, we've been deprecating TLS
1.0/1.1, which leads to issues on some Macs[46], which leads to a
question from Guido that isn't answered yet[47].
And other volunteers wrote, by my count, 21 pull requests that we merged
over the last 2 weeks[48]. jonparrott, nitinprakash96, venthur, pgadige,
saxenanurag, cheungnj, yeraydiazdiaz, AyumuKasuga, jMuzsik, and
aalmazan, thank you so much for all your work! I am particularly
grateful that our volunteers are helping review each other's work, which
helps everyone learn and improve PRs faster.

How you can help:

 * forward the beta announcement[49] to downstreams
 * tell people on Macs to upgrade pip[50], and answer Guido's
   question[51] about which users are potentially affected
 * test[52] Warehouse pull requests, and consider making one[53]
 * talk with Nicole about being a subject or interviewer for user
   tests[54]
 * improve the official Python packaging guide[55]
 * remind well-off companies/foundations you know that further Warehouse
   work is more likely if they give the PSF donations[56],
   sponsorship[57], or grants
Thanks again to the Mozilla Open Source Support grant[58] that makes
this work possible.
--
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
sh at changeset.nyc

Links:

   1. https://wiki.python.org/psf/WarehouseRoadmap
   2. https://wiki.python.org/psf/PackagingWG/2018-04-02-Warehouse
   3. https://github.com/pypa/warehouse/issues/3411
   4. https://warehouse.readthedocs.io/api-reference/integration-guide/#migrating-to-the-new-pypi
   5. https://warehouse.readthedocs.io/api-reference/integration-guide/#migrating-to-the-new-pypi
   6. https://mail.python.org/mm3/mailman3/lists/pypi-announce.python.org/
   7. https://pyfound.blogspot.com/2018/03/warehouse-all-new-pypi-is-now-in-beta.html
   8. http://status.python.org/
   9. https://mail.python.org/mm3/mailman3/lists/pypi-announce.python.org/
  10. https://github.com/pypa/warehouse/milestones
  11. https://github.com/pypa/warehouse/pull/3503
  12. https://github.com/pypa/warehouse/pull/3333
  13. https://github.com/pypa/warehouse/pull/3327
  14. https://github.com/pypa/warehouse/pull/3477
  15. https://github.com/pypa/warehouse/pull/3393
  16. https://github.com/pypa/warehouse/pull/3434
  17. https://github.com/pypa/warehouse/pull/3418
  18. https://github.com/pypa/warehouse/pull/3372
  19. https://github.com/pypa/warehouse/pull/3396
  20. https://github.com/pypa/warehouse/pull/3457
  21. https://github.com/pypa/warehouse/pull/3459
  22. https://github.com/pypa/warehouse/pull/3475
  23. https://github.com/pypa/warehouse/pull/3429
  24. https://github.com/pypa/warehouse/labels/cross%20browser%20bug%20%3Abug%3A
  25. https://github.com/pypa/conveyor/pull/3
  26. https://github.com/pypa/pypi-legacy/commits?author=ewdurbin&since=2018-03-01T05:00:00Z&until=2018-04-01T04:00:00Z
  27. https://github.com/pypa/warehouse/pull/3522
  28. https://github.com/pypa/warehouse/pull/3498
  29. https://github.com/pypa/warehouse/pull/3320
  30. https://github.com/pypa/warehouse/pull/3466
  31. https://github.com/pypa/warehouse/pull/3493
  32. https://github.com/pypa/warehouse/pull/3403
  33. https://github.com/pypa/warehouse/pull/3354
  34. http://kafka.dcpython.org/day/pypa-dev/2018-04-03
  35. https://blog.python.org/2018/03/the-all-new-python-package-index-is-now.html
  36. https://mail.python.org/pipermail/python-announce-list/2018-March/011883.html
  37. https://lists.debian.org/debian-python/2018/04/msg00000.html
  38. https://groups.google.com/forum/#!topic/python-brasil/Synj27Fczww
  39. https://www.facebook.com/groups/pythonpl/permalink/1680880335336289/
  40. http://lists.software-carpentry.org/pipermail/discuss/2018-March/005891.html
  41. https://groups.google.com/forum/#!topic/numfocus/uu8aGRmQ-oc
  42. https://changelog.com/news/the-new-pypi-is-finally-in-beta-l66G
  43. https://twit.tv/shows/floss-weekly
  44. https://www.google.com/calendar/event?eid=cTNzdDByZWxmOGRsaXRiMWo3ZXJvY2lwaW9fMjAxODAzMjdUMTkwMDAwWiA1dm90czZraGxlNm02dnNzdWFsdDJvZjg3MEBn&ctz=America/New_York
  45. https://twitter.com/hashtag/newpypi?src=hash
  46. https://mail.python.org/pipermail/python-announce-list/2018-April/011885.html
  47. https://github.com/pypa/warehouse/issues/3293#issuecomment-378416605
  48. https://github.com/pypa/warehouse/pulls?utf8=%E2%9C%93&q=3410+3448+3467+3322+3495+3412+3405+3485+3243+3535+2163+3533+3500+3415+3407+3314+3328+3202+3377+3388+3409+
  49. https://mail.python.org/pipermail/python-announce-list/2018-March/011883.html
  50. https://mail.python.org/pipermail/python-announce-list/2018-April/011885.html
  51. https://github.com/pypa/warehouse/issues/3293#issuecomment-378416605
  52. https://warehouse.readthedocs.io/development/reviewing-patches/#testing-branches-on-your-local-machine
  53. https://warehouse.readthedocs.io/development/getting-started/
  54. http://whoisnicoleharris.com/2018/03/13/user-testing-warehouse.html
  55. https://github.com/pypa/python-packaging-user-guide/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22
  56. https://donate.pypi.org/
  57. https://www.python.org/psf/sponsorship/
  58. https://pyfound.blogspot.com/2017/11/the-psf-awarded-moss-grant-pypi.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180403/0b34c37f/attachment.html>

From usercreate098 at gmail.com  Wed Apr  4 02:28:23 2018
From: usercreate098 at gmail.com (Keisha Alexander)
Date: Wed, 04 Apr 2018 06:28:23 +0000
Subject: [Distutils] (no subject)
Message-ID: <CAMOFdk_DkMG06ui3SM1FU8CG1k61WNEVZvrZ07Hc=Mmuq6urew@mail.gmail.com>

How can I get my Ip Address changed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180404/e034bceb/attachment-0001.html>

From xiaobing.gao_2 at nxp.com  Wed Apr  4 03:25:28 2018
From: xiaobing.gao_2 at nxp.com (X.b. Gao)
Date: Wed, 4 Apr 2018 07:25:28 +0000
Subject: [Distutils] how can I get the pdf version of library
Message-ID: <HE1PR0401MB2585D5002FCF5B689304E253E4A40@HE1PR0401MB2585.eurprd04.prod.outlook.com>

Dear
   Could you please help to understand if I can get the pdf version of library ? then I can look up modules of library locally and easily.

Thanks
Kind Regards,
X.B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180404/3f73720c/attachment.html>

From jonwayne at google.com  Wed Apr  4 13:26:30 2018
From: jonwayne at google.com (Jon Wayne Parrott)
Date: Wed, 04 Apr 2018 17:26:30 +0000
Subject: [Distutils] Github-Flavored Markdown is now supported on PyPI
Message-ID: <CAN6JEymbjqQ6SgGRrRFWD8+ZhGSRCLgSbL=s0K2VuYZeeszuTA@mail.gmail.com>

Hi distutils-sig,
If you haven't yet heard, as of April 1st PyPI (warehouse) supports
GitHub-Flavored Markdown for project descriptions.

You can read more about this here:
http://blog.jonparrott.com/github-flavored-markdown-on-pypi/

Thanks all!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180404/303e96a7/attachment.html>

From thomas at kluyver.me.uk  Wed Apr  4 14:31:28 2018
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Wed, 04 Apr 2018 19:31:28 +0100
Subject: [Distutils] Github-Flavored Markdown is now supported on PyPI
In-Reply-To: <CAN6JEymbjqQ6SgGRrRFWD8+ZhGSRCLgSbL=s0K2VuYZeeszuTA@mail.gmail.com>
References: <CAN6JEymbjqQ6SgGRrRFWD8+ZhGSRCLgSbL=s0K2VuYZeeszuTA@mail.gmail.com>
Message-ID: <1522866688.593387.1326653416.78BD1B8C@webmail.messagingengine.com>

A soon-to-be released version of flit will should make use of this
automatically if your description file has a .md extension.

On Wed, Apr 4, 2018, at 6:26 PM, Jon Wayne Parrott via Distutils-SIG wrote:> Hi distutils-sig,
> If you haven't yet heard, as of April 1st PyPI (warehouse) supports
> GitHub-Flavored Markdown for project descriptions.> 
> You can read more about this here:
> http://blog.jonparrott.com/github-flavored-markdown-on-pypi/> 
> Thanks all!
> _________________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180404/5dbac0c5/attachment.html>

From tritium-list at sdamon.com  Wed Apr  4 16:55:07 2018
From: tritium-list at sdamon.com (Alex Walters)
Date: Wed, 4 Apr 2018 16:55:07 -0400
Subject: [Distutils] [Python-ideas] Pypi private repo's
In-Reply-To: <CAMDiXv+0E9tsDwkNC_8LqbDvVpbsJ_93jbEA33_vBNyKspbL+Q@mail.gmail.com>
References: <CAMDiXv+0E9tsDwkNC_8LqbDvVpbsJ_93jbEA33_vBNyKspbL+Q@mail.gmail.com>
Message-ID: <3075001d3cc57$370df900$a529eb00$@sdamon.com>

I am fairly sure if you give the PyPA that suggestion, they will just deflate at the thought of the workload.  Besides, we already offer private repos for free, several ways ranging from devpi to python -m SimpleHTTPServer in a specially created directory.

 

 

From: Python-ideas <python-ideas-bounces+tritium-list=sdamon.com at python.org> On Behalf Of Nick Humrich
Sent: Wednesday, April 4, 2018 12:26 PM
To: python-ideas at python.org
Subject: [Python-ideas] Pypi private repo's

 

I am sure this has been discussed before, and this might not even be the best place for this discussion, but I just wanted to make sure this has been thought about.

What if pypi.org <http://pypi.org>  supported private repos at a cost, similar to npm?

This would be able to help support the cost of pypi, and hopefully make it better/more reliable, thus in turn improving the python community.

If this discussion should happen somewhere else, let me know.

Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180404/3122bd40/attachment.html>

From di at di.codes  Wed Apr  4 17:24:49 2018
From: di at di.codes (Dustin Ingram)
Date: Wed, 4 Apr 2018 16:24:49 -0500
Subject: [Distutils] [Python-ideas] Pypi private repo's
In-Reply-To: <3075001d3cc57$370df900$a529eb00$@sdamon.com>
References: <CAMDiXv+0E9tsDwkNC_8LqbDvVpbsJ_93jbEA33_vBNyKspbL+Q@mail.gmail.com>
 <3075001d3cc57$370df900$a529eb00$@sdamon.com>
Message-ID: <CACHw_mS0cOEkeUZUQs2oRR_nevxDcFJ-cAW=1t=Q=F53+G4z2w@mail.gmail.com>

This was recently discussed on the Packaging-WG mailing list. To
summarize, there are a few key reasons why this would be challenging:

1) The PSF is a non-profit. Taking on work generally in the domain of
for-profit enterprises might jeopardize our tax-exempt status.

2) PyPI relies heavily (~$1M/yr) on donated services and
infrastructure. If we start trying to make money, our sponsors may not
appreciate it.

3) If PyPI is in the business of hosting private packages, it may
de-incentivize us from helping to make sure "competing" private
indices (devpi, Artifactory, gemfury, etc) are functional.

4) With the exception of the current MOSS grant, PyPI is supported
entirely by unpaid volunteers. Is it fair to ask volunteers to
continue contributing their time to a for-profit enterprise?

Not to say that this would be impossible -- PyCon is quite similar
(turns a profit, has sponsors, competes with other conferences, uses
volunteer support) has addressed (and is addressing) many of these
challenges, but it remains that the transition would be challenging.

D.

On Wed, Apr 4, 2018 at 3:55 PM, Alex Walters <tritium-list at sdamon.com> wrote:
> I am fairly sure if you give the PyPA that suggestion, they will just
> deflate at the thought of the workload.  Besides, we already offer private
> repos for free, several ways ranging from devpi to python -m
> SimpleHTTPServer in a specially created directory.
>
>
>
>
>
> From: Python-ideas <python-ideas-bounces+tritium-list=sdamon.com at python.org>
> On Behalf Of Nick Humrich
> Sent: Wednesday, April 4, 2018 12:26 PM
> To: python-ideas at python.org
> Subject: [Python-ideas] Pypi private repo's
>
>
>
> I am sure this has been discussed before, and this might not even be the
> best place for this discussion, but I just wanted to make sure this has been
> thought about.
>
> What if pypi.org supported private repos at a cost, similar to npm?
>
> This would be able to help support the cost of pypi, and hopefully make it
> better/more reliable, thus in turn improving the python community.
>
> If this discussion should happen somewhere else, let me know.
>
> Nick
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>

From ja.geb at me.com  Wed Apr  4 17:58:12 2018
From: ja.geb at me.com (Jannis Gebauer)
Date: Wed, 04 Apr 2018 23:58:12 +0200
Subject: [Distutils] [Python-ideas] Pypi private repo's
In-Reply-To: <CACHw_mS0cOEkeUZUQs2oRR_nevxDcFJ-cAW=1t=Q=F53+G4z2w@mail.gmail.com>
References: <CAMDiXv+0E9tsDwkNC_8LqbDvVpbsJ_93jbEA33_vBNyKspbL+Q@mail.gmail.com>
 <3075001d3cc57$370df900$a529eb00$@sdamon.com>
 <CACHw_mS0cOEkeUZUQs2oRR_nevxDcFJ-cAW=1t=Q=F53+G4z2w@mail.gmail.com>
Message-ID: <2A893F9F-C4CE-4470-BC1D-F556A7DA5253@me.com>

What if there was some kind of ?blessed? entity that runs these services and puts the majority of the revenue into a fund that funds development on PyPi (maybe trough the PSF)? 

Jannis

> On 4. Apr 2018, at 23:24, Dustin Ingram <di at di.codes> wrote:
> 
> This was recently discussed on the Packaging-WG mailing list. To
> summarize, there are a few key reasons why this would be challenging:
> 
> 1) The PSF is a non-profit. Taking on work generally in the domain of
> for-profit enterprises might jeopardize our tax-exempt status.
> 
> 2) PyPI relies heavily (~$1M/yr) on donated services and
> infrastructure. If we start trying to make money, our sponsors may not
> appreciate it.
> 
> 3) If PyPI is in the business of hosting private packages, it may
> de-incentivize us from helping to make sure "competing" private
> indices (devpi, Artifactory, gemfury, etc) are functional.
> 
> 4) With the exception of the current MOSS grant, PyPI is supported
> entirely by unpaid volunteers. Is it fair to ask volunteers to
> continue contributing their time to a for-profit enterprise?
> 
> Not to say that this would be impossible -- PyCon is quite similar
> (turns a profit, has sponsors, competes with other conferences, uses
> volunteer support) has addressed (and is addressing) many of these
> challenges, but it remains that the transition would be challenging.
> 
> D.
> 
> On Wed, Apr 4, 2018 at 3:55 PM, Alex Walters <tritium-list at sdamon.com> wrote:
>> I am fairly sure if you give the PyPA that suggestion, they will just
>> deflate at the thought of the workload.  Besides, we already offer private
>> repos for free, several ways ranging from devpi to python -m
>> SimpleHTTPServer in a specially created directory.
>> 
>> 
>> 
>> 
>> 
>> From: Python-ideas <python-ideas-bounces+tritium-list=sdamon.com at python.org>
>> On Behalf Of Nick Humrich
>> Sent: Wednesday, April 4, 2018 12:26 PM
>> To: python-ideas at python.org
>> Subject: [Python-ideas] Pypi private repo's
>> 
>> 
>> 
>> I am sure this has been discussed before, and this might not even be the
>> best place for this discussion, but I just wanted to make sure this has been
>> thought about.
>> 
>> What if pypi.org supported private repos at a cost, similar to npm?
>> 
>> This would be able to help support the cost of pypi, and hopefully make it
>> better/more reliable, thus in turn improving the python community.
>> 
>> If this discussion should happen somewhere else, let me know.
>> 
>> Nick
>> 
>> 
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


From sh at changeset.nyc  Wed Apr  4 21:56:23 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Wed, 4 Apr 2018 21:56:23 -0400
Subject: [Distutils] IRC/Twitter livechats about Warehouse today &
 Thursday
In-Reply-To: <9d54feee-7888-387b-9708-6c0ea438fedd@changeset.nyc>
References: <759b103e-6452-0f5d-1013-7e51a07a6dad@changeset.nyc>
 <9d54feee-7888-387b-9708-6c0ea438fedd@changeset.nyc>
Message-ID: <546267dc-8ad2-b5dd-2e98-7b8fb9019337@changeset.nyc>

The next chat will be in a little under half a day.

We're also adding one more IRC livechat, for next week: Tuesday, April
10th, 19:00 UTC:
https://www.timeanddate.com/worldclock/converter.html?iso=20180410T190000&p1=24&p2=1440&p3=179
.

-Sumana


On 04/03/2018 10:44 AM, Sumana Harihareswara wrote:
> The next one starts in ~16 minutes. Links, etc. at
> https://pyfound.blogspot.com/2018/03/warehouse-all-new-pypi-is-now-in-beta.html#livechat
> .
> 
> -Sumana
> 
> On 03/26/2018 05:13 PM, Sumana Harihareswara wrote:
>> Warehouse developers will be in IRC, in #pypa-dev on Freenode, and on
>> Twitter (hashtag: #newpypi), available to talk about problems you run
>> into, or about how to hack on Warehouse, for four livechats over the
>> next few weeks:
>>
>>
>> 1. Tuesday, March 27th, 9am-10am PDT, noon-1pm EDT, 18:00-19:00 CEST,
>> 9:30pm-10:30pm India, 16:00-17:00 UTC
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Warehouse/PyPI+beta+chat&iso=20180327T16&p1=:&ah=1
>>
>>
>> 2. Friday, March 30th, 10-11am EDT, 16:00-17:00 CEST, 7:30pm-8:30pm
>> India, 14:00-15:00 UTC
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Warehouse/PyPI+beta+live+chat&iso=20180330T14&p1=1440&ah=1
>>
>>
>> 3.  Tuesday, April 3rd, 8am-9am PDT, 11am-noon EDT, 17:00-18:00 CEST,
>> 8:30pm-9:30pm India, 15:00-16:00 UTC
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Warehouse/PyPI+beta+livechat&iso=20180403T10&p1=24&ah=1
>>
>>
>> 4. Thursday, April 5th, 5pm-6pm PDT, 8pm-9pm EDT, (April 5th) 8am-9am
>> Manila, (April 5th) 10am-11am Melbourne, (April 5th) 0:00-1:00 UTC
>> https://www.timeanddate.com/worldclock/fixedtime.html?p1=24&iso=20180405T19&msg=Warehouse/PyPI%20beta%20livechat&ah=1&low=4
>>
>>
>> Feel free to drop in! (By participating, you agree to abide by the PyPA
>> Code of Conduct: https://www.pypa.io/en/latest/code-of-conduct/ .)
>>


From ericgorr at gmail.com  Wed Apr  4 21:11:51 2018
From: ericgorr at gmail.com (Eric Gorr)
Date: Thu, 05 Apr 2018 01:11:51 +0000
Subject: [Distutils] Distributing packages to offline machines
Message-ID: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>

I had a question about distributing python packages to offline machines
when the offline machine is running a different OS then a machine with an
internet connection. The packages I am concerned with are third party upon
which mine depend.

Based on what I have learned so far, there are three solutions.

(a) Use a CI to run a fleet of machines for each OS one needs to target to
obtain the OS specific wheels.

(b) 'pip download <package_list> --no-binary :all:' -- the intention here
is to grab the source distribution without any OS specific code included.

(c) use https://warehouse.pypa.io/api-reference/json to look for
distributed wheels for the target OS and python version and download them
directly. (This may make for a nice flag to add to pip somewhere...the
ability to specify what wheel one wants when it isn?t for the machine pip
is running on)

The issue I see with (a) is the shear amount work it would take to setup
and maintain such a system.

The issue I see with (b) is that it is not 100% reliable as some packages
are tricky to install and may not work well with 'pip download?.

I have not played around with (c) yet, so I do not know how well it will
work, but it seems like a viable solution.

I was just wondering if anyone had any comments on this as I think though
the ways to solve this problem.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180405/ed42087c/attachment.html>

From wes.turner at gmail.com  Thu Apr  5 01:26:41 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Thu, 5 Apr 2018 01:26:41 -0400
Subject: [Distutils] Distributing packages to offline machines
In-Reply-To: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
References: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
Message-ID: <CACfEFw_Ecd7z0SweyF2kdWtsSwMY824_62GWdd6JJk3=1Vubig@mail.gmail.com>

Have you already tried `pip download --platform`?

https://pip.pypa.io/en/stable/reference/pip_download/#cmdoption-platform


It may be worth setting up devpi (maybe in a container) and caching the
packages; particularly for CI:

https://packaging.python.org/guides/index-mirrors-and-caches/

AFAIU, there's no way to specify a limited set of packages and platforms to
mirror with bandersnatch?

On Wednesday, April 4, 2018, Eric Gorr <ericgorr at gmail.com> wrote:

> I had a question about distributing python packages to offline machines
> when the offline machine is running a different OS then a machine with an
> internet connection. The packages I am concerned with are third party upon
> which mine depend.
>
> Based on what I have learned so far, there are three solutions.
>
> (a) Use a CI to run a fleet of machines for each OS one needs to target to
> obtain the OS specific wheels.
>
> (b) 'pip download <package_list> --no-binary :all:' -- the intention here
> is to grab the source distribution without any OS specific code included.
>
> (c) use https://warehouse.pypa.io/api-reference/json to look for
> distributed wheels for the target OS and python version and download them
> directly. (This may make for a nice flag to add to pip somewhere...the
> ability to specify what wheel one wants when it isn?t for the machine pip
> is running on)
>
> The issue I see with (a) is the shear amount work it would take to setup
> and maintain such a system.
>
> The issue I see with (b) is that it is not 100% reliable as some packages
> are tricky to install and may not work well with 'pip download?.
>
> I have not played around with (c) yet, so I do not know how well it will
> work, but it seems like a viable solution.
>
> I was just wondering if anyone had any comments on this as I think though
> the ways to solve this problem.
>
> Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180405/97324060/attachment.html>

From thomas at kluyver.me.uk  Thu Apr  5 07:21:29 2018
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Thu, 05 Apr 2018 12:21:29 +0100
Subject: [Distutils] Distributing packages to offline machines
In-Reply-To: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
References: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
Message-ID: <1522927289.1590092.1327428936.7376A997@webmail.messagingengine.com>

On Thu, Apr 5, 2018, at 2:11 AM, Eric Gorr wrote:
> (c) use https://warehouse.pypa.io/api-reference/json to look for
>     distributed wheels for the target OS and python version and
>     download them directly. (This may make for a nice flag to add to
>     pip somewhere...the ability to specify what wheel one wants when
>     it isn?t for the machine pip is running on)
If it's useful, Pynsist includes some code to find and download wheels
for Windows, regardless of the platform it runs on:
https://github.com/takluyver/pynsist/blob/master/nsist/pypi.py

Pynsist is a tool to make Windows installers. The tool can also run on
Linux and Mac, but it always builds Windows installers. I didn't know
about "pip download --platform" when I wrote this - it may be redundant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180405/b38fa3c4/attachment-0001.html>

From ncoghlan at gmail.com  Fri Apr  6 08:34:34 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 6 Apr 2018 22:34:34 +1000
Subject: [Distutils] [Python-ideas] Pypi private repo's
In-Reply-To: <2A893F9F-C4CE-4470-BC1D-F556A7DA5253@me.com>
References: <CAMDiXv+0E9tsDwkNC_8LqbDvVpbsJ_93jbEA33_vBNyKspbL+Q@mail.gmail.com>
 <3075001d3cc57$370df900$a529eb00$@sdamon.com>
 <CACHw_mS0cOEkeUZUQs2oRR_nevxDcFJ-cAW=1t=Q=F53+G4z2w@mail.gmail.com>
 <2A893F9F-C4CE-4470-BC1D-F556A7DA5253@me.com>
Message-ID: <CADiSq7dHw_8AdWrJidMrzHbEi+Z681mDMAQSksmJAEgiZA_UCA@mail.gmail.com>

On 5 April 2018 at 07:58, Jannis Gebauer <ja.geb at me.com> wrote:
> What if there was some kind of ?blessed? entity that runs these services and puts the majority of the revenue into a fund that funds development on PyPi (maybe trough the PSF)?

Having a wholly owned for-profit subsidiary that provides commercial
services as a revenue raising mechanism is certainly one way to
approach something like this without alienating sponsors or tax
authorities (although it may still alienate the vendors of now
competing services). It would require a big time commitment on the PSF
side to get everything set up though, as well as interest from key
folks in joining what would essentially be a single-language-focused
start up in an already crowded cross-language developer tools
marketplace. When the PSF as a whole is still operating with only a
handful of full or part time employees, it's far from clear that
setting something like that up would be the most effective possible
use of their time and energy.

At a more basic level, that kind of arrangement technically doesn't
require anyone's blessing, it could be as straightforward as
downstream tooling vendors signing up as PSF sponsors and saying
"please allocate our sponsorship contribution to the Packaging WG's
budget so that PyPI keeps operating well and the PyPA tooling keeps
improving, increasing the level of demand for our commercial Python
repository management services".

Historically that wouldn't have helped much, since the PSF itself has
struggled with effective project management (for a variety of
reasons), but one of the things I think the success of the MOSS grant
has shown is the significant strides that the PSF has made in budget
management in recent years, such that if funding is made available, it
can and will be spent effectively.

Cheers,
Nick.

P.S. PyPA contributors are also free agents in their own right, so
folks offering Python-centric developer workflow management tools or
features may decide that it's worth their while to invest more
directly in smoothing out some of the rough edges that currently still
exist. It's a mercenary way of looking at things, but in many cases,
it is *absolutely* possible to pay for the time and attention of
existing contributors, and if you can persuade them that your
proposals are reasonable, they'll often have an easier time than most
convincing other community contributors that it's a good way to go :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Fri Apr  6 08:50:09 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 6 Apr 2018 22:50:09 +1000
Subject: [Distutils] Distributing packages to offline machines
In-Reply-To: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
References: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
Message-ID: <CADiSq7ez7uOvMqJ0S4rt6f4COCYCMru7dFgaLnFiE=KNHs1nAQ@mail.gmail.com>

On 5 April 2018 at 11:11, Eric Gorr <ericgorr at gmail.com> wrote:
> I had a question about distributing python packages to offline machines when
> the offline machine is running a different OS then a machine with an
> internet connection. The packages I am concerned with are third party upon
> which mine depend.
>
> Based on what I have learned so far, there are three solutions.
>
> (a) Use a CI to run a fleet of machines for each OS one needs to target to
> obtain the OS specific wheels.
>
> The issue I see with (a) is the shear amount work it would take to setup and
> maintain such a system.

Depending on just how many packages and how many operating system
versions are involved, this option may be less work that you
anticipate, thanks to the excellent wagon project from Cloudify:
https://github.com/cloudify-cosmo/wagon

Keep a requirements.txt file or `Pipfile` in source control, then run
CI jobs based on that repo to emit wagon files with all the required
wheels embedded in them (either sourced from PyPI, or built locally in
CI as needed).

Cheers,
Nick.

P.S. See https://github.com/cloudify-cosmo/wagon/issues/30#issuecomment-374096806
for the technique of supplying a dummy setup.py file that gives wagon
the metadata it wants, without actually needing to define a full top
level "application" package.

P.P.S Depending on how strict the requirement is for "offline wheel
files" vs "offline prebuilt binary dependencies", it may also be worth
your while to explore
https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/
(regarding the use of conda as a Python platform manager) and
https://conda.io/docs/user-guide/tasks/create-custom-channels.html
(regarding the creation of tar-friendly custom conda channels)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ben+python at benfinney.id.au  Fri Apr  6 20:11:53 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 07 Apr 2018 10:11:53 +1000
Subject: [Distutils] Distributing packages to offline machines
References: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
 <CADiSq7ez7uOvMqJ0S4rt6f4COCYCMru7dFgaLnFiE=KNHs1nAQ@mail.gmail.com>
Message-ID: <85r2nrx4c6.fsf@benfinney.id.au>

Nick Coghlan <ncoghlan at gmail.com> writes:

> Keep a requirements.txt file or `Pipfile` in source control, then run
> CI jobs based on that repo [?]

What is a ?Pipfile??

-- 
 \      ?Software patents provide one more means of controlling access |
  `\      to information. They are the tool of choice for the internet |
_o__)                                     highwayman.? ?Anthony Taylor |
Ben Finney


From wes.turner at gmail.com  Fri Apr  6 22:21:20 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Fri, 6 Apr 2018 22:21:20 -0400
Subject: [Distutils] Distributing packages to offline machines
In-Reply-To: <85r2nrx4c6.fsf@benfinney.id.au>
References: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
 <CADiSq7ez7uOvMqJ0S4rt6f4COCYCMru7dFgaLnFiE=KNHs1nAQ@mail.gmail.com>
 <85r2nrx4c6.fsf@benfinney.id.au>
Message-ID: <CACfEFw9ZpE4E0Wy9iN86sLq8rFq3UhZJ2XnLmzLiDNos_=gxPQ@mail.gmail.com>

On Friday, April 6, 2018, Ben Finney <ben+python at benfinney.id.au> wrote:

> Nick Coghlan <ncoghlan at gmail.com> writes:
>
> > Keep a requirements.txt file or `Pipfile` in source control, then run
> > CI jobs based on that repo [?]
>
> What is a ?Pipfile??


https://docs.pipenv.org/

https://docs.pipenv.org/basics/#example-pipfile-pipfile-lock


>
> --
>  \      ?Software patents provide one more means of controlling access |
>   `\      to information. They are the tool of choice for the internet |
> _o__)                                     highwayman.? ?Anthony Taylor |
> Ben Finney
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180406/ae41435e/attachment.html>

From ncoghlan at gmail.com  Sat Apr  7 21:21:20 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 8 Apr 2018 11:21:20 +1000
Subject: [Distutils] Distributing packages to offline machines
In-Reply-To: <CACfEFw9ZpE4E0Wy9iN86sLq8rFq3UhZJ2XnLmzLiDNos_=gxPQ@mail.gmail.com>
References: <CALr0X58UNa=R_-13LZMycjOTeosPLkTT74Wi6i9q44_1fsQ6fw@mail.gmail.com>
 <CADiSq7ez7uOvMqJ0S4rt6f4COCYCMru7dFgaLnFiE=KNHs1nAQ@mail.gmail.com>
 <85r2nrx4c6.fsf@benfinney.id.au>
 <CACfEFw9ZpE4E0Wy9iN86sLq8rFq3UhZJ2XnLmzLiDNos_=gxPQ@mail.gmail.com>
Message-ID: <CADiSq7fuYoSo-Jgk0vLvKUSzpRD5OGpe6seG=Y+MHN=Zdtpu_Q@mail.gmail.com>

On 7 April 2018 at 12:21, Wes Turner <wes.turner at gmail.com> wrote:
>
>
> On Friday, April 6, 2018, Ben Finney <ben+python at benfinney.id.au> wrote:
>>
>> Nick Coghlan <ncoghlan at gmail.com> writes:
>>
>> > Keep a requirements.txt file or `Pipfile` in source control, then run
>> > CI jobs based on that repo [?]
>>
>> What is a ?Pipfile??
>
> https://docs.pipenv.org/
>
> https://docs.pipenv.org/basics/#example-pipfile-pipfile-lock

And some additional info is available in PyPUG's application
dependency management tutorial:
https://packaging.python.org/tutorials/managing-dependencies/

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From vinays75 at gmail.com  Sat Apr  7 23:44:45 2018
From: vinays75 at gmail.com (Vinay Sharma)
Date: Sat, 7 Apr 2018 20:44:45 -0700
Subject: [Distutils] Facing a strange issue while uploading my package
 using devpi
In-Reply-To: <CAGGBd_qLPU0TVmcbZRZyp-s=ayJ2CQOMaCvMKSY_EuaW_P_ZbA@mail.gmail.com>
References: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
 <7F5F3FA0-6BE0-404B-8225-D6AAAA337AE3@gmail.com>
 <CAAkvi+U1C5KjnoHFmVbQw9eBRY-p2m5ZTkb5taf1yGBTWiJJFw@mail.gmail.com>
 <CAGGBd_qLPU0TVmcbZRZyp-s=ayJ2CQOMaCvMKSY_EuaW_P_ZbA@mail.gmail.com>
Message-ID: <CAAkvi+XYTPCRHvVcK3b-6ARcqi_2TO+3O3XV49QKU==av+Z9oQ@mail.gmail.com>

Thanks to all who provided their valuable comments for this Issue.

Based upon the pointer provided by Dan, figured out there was a discrepancy
in the devpi version on my machine vs Jenkins build machine. After
upgrading the devpi on the Jenkins build machine the problem went away
although I am still puzzled why it came in the first place. Anyways problem
resolved.

Learned my lesson in a hard way : always keep the build and configuration
tools up-to-date.

Regards
-Vinay Sharma

On Mon, Apr 2, 2018 at 7:54 PM, Dan Stromberg <drsalists at gmail.com> wrote:

> On Mon, Apr 2, 2018 at 4:38 PM, Vinay Sharma <vinays75 at gmail.com> wrote:
> > Here are the answers to your questions and some new insights which I
> found
> > today :-
> > a) This problem happens during the Jenkins Job only. I tried the build
> steps
> > manually on my local code base (which were exactly same as my Jenkins
> Job)
> > and it uploaded the distribution file perfectly.
>
> Often when the same commands produce different results under 2
> different accounts on the same computer, it's because of an
> environment variable difference:
>
> I wrote this years ago to help track down env var issues:
> http://stromberg.dnsalias.org/~strombrg/env-search.html
>
> HTH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180407/1f2e8d33/attachment.html>

From di at di.codes  Sun Apr  8 08:16:21 2018
From: di at di.codes (Dustin Ingram)
Date: Sun, 08 Apr 2018 12:16:21 +0000
Subject: [Distutils] Facing a strange issue while uploading my package
 using devpi
In-Reply-To: <CAAkvi+XYTPCRHvVcK3b-6ARcqi_2TO+3O3XV49QKU==av+Z9oQ@mail.gmail.com>
References: <CAAkvi+VR=i1++jFzgPHRENaw=japdTAyo_XySi2O2SHO-jBgFg@mail.gmail.com>
 <7F5F3FA0-6BE0-404B-8225-D6AAAA337AE3@gmail.com>
 <CAAkvi+U1C5KjnoHFmVbQw9eBRY-p2m5ZTkb5taf1yGBTWiJJFw@mail.gmail.com>
 <CAGGBd_qLPU0TVmcbZRZyp-s=ayJ2CQOMaCvMKSY_EuaW_P_ZbA@mail.gmail.com>
 <CAAkvi+XYTPCRHvVcK3b-6ARcqi_2TO+3O3XV49QKU==av+Z9oQ@mail.gmail.com>
Message-ID: <CACHw_mSOyJN7EsLxF9ea2gwvH5nYhAAzyLnqBu8xNHoLGCtLEw@mail.gmail.com>

This is likely the reason why:
https://github.com/devpi/devpi/issues/524#comment-379020251

On Sat, Apr 7, 2018, 10:45 PM Vinay Sharma <vinays75 at gmail.com> wrote:

> Thanks to all who provided their valuable comments for this Issue.
>
> Based upon the pointer provided by Dan, figured out there was a
> discrepancy in the devpi version on my machine vs Jenkins build machine.
> After upgrading the devpi on the Jenkins build machine the problem went
> away although I am still puzzled why it came in the first place. Anyways
> problem resolved.
>
> Learned my lesson in a hard way : always keep the build and configuration
> tools up-to-date.
>
> Regards
> -Vinay Sharma
>
> On Mon, Apr 2, 2018 at 7:54 PM, Dan Stromberg <drsalists at gmail.com> wrote:
>
>> On Mon, Apr 2, 2018 at 4:38 PM, Vinay Sharma <vinays75 at gmail.com> wrote:
>> > Here are the answers to your questions and some new insights which I
>> found
>> > today :-
>> > a) This problem happens during the Jenkins Job only. I tried the build
>> steps
>> > manually on my local code base (which were exactly same as my Jenkins
>> Job)
>> > and it uploaded the distribution file perfectly.
>>
>> Often when the same commands produce different results under 2
>> different accounts on the same computer, it's because of an
>> environment variable difference:
>>
>> I wrote this years ago to help track down env var issues:
>> http://stromberg.dnsalias.org/~strombrg/env-search.html
>>
>> HTH
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180408/6b237d0f/attachment.html>

From mschwage at gmail.com  Sat Apr  7 01:48:21 2018
From: mschwage at gmail.com (Michael Schwager)
Date: Sat, 7 Apr 2018 00:48:21 -0500
Subject: [Distutils] How to install examples files?
Message-ID: <CAPm3rnYF+4Ro2DDD+UmQdxKno+ipjw62vQ0se7jiUz2Yt7BaSg@mail.gmail.com>

Hello,
I am trying to install a module with a package and also an examples
directory. How do I get my examples installed on users' machines into a
reasonable location, in a cross-platform kind of way?

 I notice that a number of Python examples are installed in /usr/share (in
Linux) or in  <home>\AppData\Local\Programs\Python\Python36\Share on
Windows 8.

So in my setup.py, I have this:

from setuptools import setup, find_packages
from codecs import open
from os import path

with open(path.join('.', 'README.md'), encoding='utf-8') as f:
   long_description = f.read()

setup(
   name='kivydnd',
   version='0.5.0',
   description='Kivy Drag-n-Drop for Widgets',
   long_description=long_description,
   long_description_content_type='text/markdown',
   url='https://github.com/GreyGnome/KivyDnD',
   author='GreyGnome',
   author_email='myemail at example.com',
   license='Apache License 2.0',
   keywords='kivy drag-n-drop',
   packages=find_packages(exclude=[]),
   data_files=[('share/kivydnd-examples', ['examples/dndexample1.py',])],
)

But when I try to install them on Linux, I don't see the dndexample1.py
file anywhere:

python setup.py sdist
pip install --target=/home/schwager/lib/python dist/kivydnd-0.5.0.tar.gz
--log /tmp/piplog

(Note that I am using a different target for testing).

The piplog shows that it at least tried to do something with the examples,
but I can find a directory by that name anywhere in my home directory:

<snippet from log>
   creating /tmp/tmpirrDx8/share/kivydnd-examples
   copying examples/dndexample1.py -> /tmp/tmpirrDx8/share/kivydnd-examples

Thanks!
-- 
-Mike Schwager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180407/d9223e69/attachment.html>

From barry at python.org  Mon Apr  9 16:22:03 2018
From: barry at python.org (Barry Warsaw)
Date: Mon, 9 Apr 2018 13:22:03 -0700
Subject: [Distutils] Renaming this list to python-packaging
In-Reply-To: <EDD1E8B4-E0CF-4E53-B6CF-C3923268E0B6@stufft.io>
References: <CAPA-EqsnE65-LpMnamyZ-4=Lg02mUWMQaVMD+fJEkY6C-Fm6sg@mail.gmail.com>
 <CACac1F-TBoQpPhcCaw5=gtPogLDvMv17eieabWY1sXHy+sij4A@mail.gmail.com>
 <EDD1E8B4-E0CF-4E53-B6CF-C3923268E0B6@stufft.io>
Message-ID: <paghtd$a8e$1@blaine.gmane.org>

Donald Stufft wrote:
> I don?t think we can rename a mailing list easily, we can create a new one and archive the old one but that has a lot of churn and breaks people?s filters, etc.

Although it should be easier to rename if the list is migrated to 
Mailman 3 first.  Please contact postmaster at p.o if you want to go that 
route.

-Barry



From chris.jerdonek at gmail.com  Mon Apr  9 19:47:42 2018
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Mon, 9 Apr 2018 16:47:42 -0700
Subject: [Distutils] providing a way for pip to communicate extra info to
 users
Message-ID: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>

On the pypa-dev Google group, a suggestion was raised about giving pip
a way to communicate extra info to users.

This was during a thread started by Matthew Brett about pip breaking
for certain macOS users due to certain TLS changes ("Impending silent
breakage of pip / macOS likely to cause severe confusion"). Donald
said this behavior is governed by PEP 503 and that the topic was best
discussed on distutils-sig:
https://groups.google.com/d/msg/pypa-dev/Oz6SGA7gefo/RRXQBQSBBAAJ
so I'm raising the suggestion here to continue the discussion.

One of Donald's comments in response to the idea (and that occurred to
me too and that I agree with) is that providing a way to communicate
messages to users introduces another possible avenue for attack.

A possible middle-ground could be to hard-code a message in pip. Pip
could display the message in certain circumstances, e.g. in response
to certain types of failures. For example, the message could tell
users to check a certain URL maintained by PyPA for further
information / possible announcements.

What do people think?

--Chris

From mschwage at gmail.com  Tue Apr 10 17:08:39 2018
From: mschwage at gmail.com (Michael Schwager)
Date: Tue, 10 Apr 2018 16:08:39 -0500
Subject: [Distutils] How to install examples files?
In-Reply-To: <CAPm3rnYF+4Ro2DDD+UmQdxKno+ipjw62vQ0se7jiUz2Yt7BaSg@mail.gmail.com>
References: <CAPm3rnYF+4Ro2DDD+UmQdxKno+ipjw62vQ0se7jiUz2Yt7BaSg@mail.gmail.com>
Message-ID: <CAPm3rnaWOUCod_UCCbESQHqzVHxUMCBFejVUmVLrZJToT5jitg@mail.gmail.com>

It looks like the following setup.py will do what I want, but it won't
install the examples when I use --target:

from setuptools import setup, find_packages
from codecs import open
from os import path

with open(path.join('.', 'README.md'), encoding='utf-8') as f:
   long_description = f.read()

setup(
   name='kivydnd',
   version='0.5.0',
   description='Kivy Drag-n-Drop for Widgets',
   long_description=long_description,
   long_description_content_type='text/markdown',
   url='https://github.com/GreyGnome/KivyDnD',
   author='GreyGnome',
   author_email='mschwage at gmail.com',
   license='Apache License 2.0',
   keywords='kivy drag-n-drop',
   packages=find_packages(exclude=[]),
   data_files=[('share/kivydnd-examples',
       [
           'examples/dndexample1.py',
           'examples/dndexample2.py',
           'examples/dndexample3.py',
           'examples/dndexample_copy_draggable.py',
           'examples/dndexample_drop_groups.py',
           'examples/dndexample_relative_layout.py',
           'examples/example_base_classes.py',
           'examples/example_base_classes.pyc',
       ]
   )],
)


On Sat, Apr 7, 2018 at 12:48 AM, Michael Schwager <mschwage at gmail.com>
wrote:

> Hello,
> I am trying to install a module with a package and also an examples
> directory. How do I get my examples installed on users' machines into a
> reasonable location, in a cross-platform kind of way?
>
>  I notice that a number of Python examples are installed in /usr/share (in
> Linux) or in  <home>\AppData\Local\Programs\Python\Python36\Share on
> Windows 8.
>
> So in my setup.py, I have this:
>
> from setuptools import setup, find_packages
> from codecs import open
> from os import path
>
> with open(path.join('.', 'README.md'), encoding='utf-8') as f:
>    long_description = f.read()
>
> setup(
>    name='kivydnd',
>    version='0.5.0',
>    description='Kivy Drag-n-Drop for Widgets',
>    long_description=long_description,
>    long_description_content_type='text/markdown',
>    url='https://github.com/GreyGnome/KivyDnD',
>    author='GreyGnome',
>    author_email='myemail at example.com',
>    license='Apache License 2.0',
>    keywords='kivy drag-n-drop',
>    packages=find_packages(exclude=[]),
>    data_files=[('share/kivydnd-examples', ['examples/dndexample1.py',])],
> )
>
> But when I try to install them on Linux, I don't see the dndexample1.py
> file anywhere:
>
> python setup.py sdist
> pip install --target=/home/schwager/lib/python dist/kivydnd-0.5.0.tar.gz
> --log /tmp/piplog
>
> (Note that I am using a different target for testing).
>
> The piplog shows that it at least tried to do something with the examples,
> but I can find a directory by that name anywhere in my home directory:
>
> <snippet from log>
>    creating /tmp/tmpirrDx8/share/kivydnd-examples
>    copying examples/dndexample1.py -> /tmp/tmpirrDx8/share/kivydnd-
> examples
>
> Thanks!
> --
> -Mike Schwager
>



-- 
-Mike Schwager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180410/b6f844e0/attachment.html>

From laura at laura-hampton.com  Tue Apr 10 16:52:27 2018
From: laura at laura-hampton.com (Laura Hampton)
Date: Tue, 10 Apr 2018 16:52:27 -0400
Subject: [Distutils] PyPI/Warehouse (short) weekly report: Progress towards
 launch milestone
Message-ID: <1523393547.616664.1333497704.468DBDDB@webmail.messagingengine.com>

(This week's report will be a brief update, written by Laura Hampton. Sumana will return later this week.)   

We are continuing to approach the Launch: Redirect pypi.python.org to pypi.org milestone[1]. The redirect is scheduled to happen on Monday, April 16th.  The Warehouse team has been busy closing and responding to issues from legacy PyPI [2], and Dustin is already preparing to remove the beta banner from Warehouse when we reach the Launch milestone[3]. Ernest is working on load-testing infrastructure in anticipation of the launch. We have continued to work on user testing[4], improving accessibility[5], and making changes based on our testers' feedback[6]. Thank you to Nicole for running the tests, and to everyone who helped test and contributed feedback.   

You can help this week by opining in our "needs discussion" issues [7]. If you have expertise in JavaScript, please consider looking at our frontend testing approach[8].  If you are new to the project, please check out our issues labeled "good first issue", or consider contacting Nicole about being a subject or interviewer for user tests[9].  If you will be at PyCon US in Cleveland next month, we will be sprinting, and we'd love to have you join us[10].

Thanks to Mozilla for their support for the PyPI & Warehouse work![11][12]  

Laura Hampton
Laura at laura-hampton . com 

[1]https://github.com/pypa/warehouse/milestone/1 
[2] https://github.com/pypa/pypi-legacy/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc 
[3]https://github.com/pypa/warehouse/pull/3566 
[4] https://github.com/pypa/warehouse/issues/1317 
[5] https://github.com/pypa/warehouse/issues/3334 
[6] https://github.com/pypa/warehouse/issues/3162
[7] https://github.com/pypa/warehouse/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22needs+discussion%22 
[8] https://github.com/pypa/warehouse/issues/1297 
[9]http://whoisnicoleharris.com/2018/03/13/user-testing-warehouse.html 
[10] https://wiki.python.org/psf/PackagingSprints 
[11] https://pyfound.blogspot.com/2017/11/the-psf-awarded-moss-grant-pypi.html 
[12] https://blog.mozilla.org/blog/2018/01/23/moss-q4-supporting-python-ecosystem/

From g.rodola at gmail.com  Wed Apr 11 01:07:31 2018
From: g.rodola at gmail.com (Giampaolo Rodola')
Date: Wed, 11 Apr 2018 05:07:31 +0000
Subject: [Distutils] How to install examples files?
In-Reply-To: <CAPm3rnYF+4Ro2DDD+UmQdxKno+ipjw62vQ0se7jiUz2Yt7BaSg@mail.gmail.com>
References: <CAPm3rnYF+4Ro2DDD+UmQdxKno+ipjw62vQ0se7jiUz2Yt7BaSg@mail.gmail.com>
Message-ID: <CAFYqXL-S_bzGU7F2VKtqLb_LQqrBrfKz__ys5oVzd+eFy4dsUQ@mail.gmail.com>

That?s likely because dndexample1.py is not listed in MANIFEST.in file.

On Mon, 9 Apr 2018 at 10:10, Michael Schwager <mschwage at gmail.com> wrote:

> Hello,
> I am trying to install a module with a package and also an examples
> directory. How do I get my examples installed on users' machines into a
> reasonable location, in a cross-platform kind of way?
>
>  I notice that a number of Python examples are installed in /usr/share (in
> Linux) or in  <home>\AppData\Local\Programs\Python\Python36\Share on
> Windows 8.
>
> So in my setup.py, I have this:
>
> from setuptools import setup, find_packages
> from codecs import open
> from os import path
>
> with open(path.join('.', 'README.md'), encoding='utf-8') as f:
>    long_description = f.read()
>
> setup(
>    name='kivydnd',
>    version='0.5.0',
>    description='Kivy Drag-n-Drop for Widgets',
>    long_description=long_description,
>    long_description_content_type='text/markdown',
>    url='https://github.com/GreyGnome/KivyDnD',
>    author='GreyGnome',
>    author_email='myemail at example.com',
>    license='Apache License 2.0',
>    keywords='kivy drag-n-drop',
>    packages=find_packages(exclude=[]),
>    data_files=[('share/kivydnd-examples', ['examples/dndexample1.py',])],
> )
>
> But when I try to install them on Linux, I don't see the dndexample1.py
> file anywhere:
>
> python setup.py sdist
> pip install --target=/home/schwager/lib/python dist/kivydnd-0.5.0.tar.gz
> --log /tmp/piplog
>
> (Note that I am using a different target for testing).
>
> The piplog shows that it at least tried to do something with the examples,
> but I can find a directory by that name anywhere in my home directory:
>
> <snippet from log>
>    creating /tmp/tmpirrDx8/share/kivydnd-examples
>    copying examples/dndexample1.py -> /tmp/tmpirrDx8/share/kivydnd-examples
>
> Thanks!
> --
> -Mike Schwager
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/9e8cba55/attachment-0001.html>

From thomas at kluyver.me.uk  Wed Apr 11 04:04:19 2018
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Wed, 11 Apr 2018 09:04:19 +0100
Subject: [Distutils] How to install examples files?
In-Reply-To: <CAPm3rnaWOUCod_UCCbESQHqzVHxUMCBFejVUmVLrZJToT5jitg@mail.gmail.com>
References: <CAPm3rnYF+4Ro2DDD+UmQdxKno+ipjw62vQ0se7jiUz2Yt7BaSg@mail.gmail.com>
 <CAPm3rnaWOUCod_UCCbESQHqzVHxUMCBFejVUmVLrZJToT5jitg@mail.gmail.com>
Message-ID: <1523433859.1941951.1333989144.1EE1C970@webmail.messagingengine.com>

If I recall correctly, 'pip install --target' works by installing into a
temporary directory, then copying only the library part to the target
directory. So it will throw away any docs/examples/scripts that would be
installed outside the importable package.

On Tue, Apr 10, 2018, at 10:08 PM, Michael Schwager wrote:
> It looks like the following setup.py will do what I want, but it won't
> install the examples when I use --target:> 
> from setuptools import setup, find_packages
> from codecs import open
> from os import path
> 
> with open(path.join('.', 'README.md'), encoding='utf-8') as f:
>    long_description = f.read()
> 
> setup(
>    name='kivydnd',
>    version='0.5.0',
>    description='Kivy Drag-n-Drop for Widgets',
>    long_description=long_description,
>    long_description_content_type='text/markdown',
>    url='https://github.com/GreyGnome/KivyDnD',
>    author='GreyGnome',
>    author_email='mschwage at gmail.com',
>    license='Apache License 2.0',
>    keywords='kivy drag-n-drop',
>    packages=find_packages(exclude=[]),
>    data_files=[('share/kivydnd-examples',
>        [
>            'examples/dndexample1.py',
>            'examples/dndexample2.py',
>            'examples/dndexample3.py',
>            'examples/dndexample_copy_draggable.py',
>            'examples/dndexample_drop_groups.py',
>            'examples/dndexample_relative_layout.py',
>            'examples/example_base_classes.py',
>            'examples/example_base_classes.pyc',
>        ]
>    )],
> )
> 
> 
> On Sat, Apr 7, 2018 at 12:48 AM, Michael Schwager
> <mschwage at gmail.com> wrote:>> Hello,
>> I am trying to install a module with a package and also an examples
>> directory. How do I get my examples installed on users' machines into
>> a reasonable location, in a cross-platform kind of way?>> 
>>  I notice that a number of Python examples are installed in
>>  /usr/share (in Linux) or in
>>  <home>\AppData\Local\Programs\Python\Python36\Share on Windows 8.>> 
>> So in my setup.py, I have this:
>> 
>> from setuptools import setup, find_packages
>> from codecs import open
>> from os import path
>> 
>> with open(path.join('.', 'README.md'), encoding='utf-8') as f:
>>    long_description = f.read()
>> 
>> setup(
>>    name='kivydnd',
>>    version='0.5.0',
>>    description='Kivy Drag-n-Drop for Widgets',
>>    long_description=long_description,
>>    long_description_content_type='text/markdown',
>>    url='https://github.com/GreyGnome/KivyDnD',
>>    author='GreyGnome',
>>    author_email='myemail at example.com',
>>    license='Apache License 2.0',
>>    keywords='kivy drag-n-drop',
>>    packages=find_packages(exclude=[]),
>>    data_files=[('share/kivydnd-examples',
>>    ['examples/dndexample1.py',])],>> )
>> 
>> But when I try to install them on Linux, I don't see the
>> dndexample1.py file anywhere:>> 
>> python setup.py sdist
>> pip install --target=/home/schwager/lib/python dist/kivydnd-
>> 0.5.0.tar.gz --log /tmp/piplog>> 
>> (Note that I am using a different target for testing).
>> 
>> The piplog shows that it at least tried to do something with the
>> examples, but I can find a directory by that name anywhere in my home
>> directory:>> 
>> <snippet from log>
>>    creating /tmp/tmpirrDx8/share/kivydnd-examples
>>    copying examples/dndexample1.py -> /tmp/tmpirrDx8/share/kivydnd-
>>    examples>> 
>> Thanks!
>> -- 
>> -Mike Schwager
>> 
> 
> 
> 
> -- 
> -Mike Schwager
> _________________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/a63d3e68/attachment.html>

From jorgesumle at freakspot.net  Wed Apr 11 06:55:04 2018
From: jorgesumle at freakspot.net (Jorge Maldonado Ventura)
Date: Wed, 11 Apr 2018 12:55:04 +0200
Subject: [Distutils] Execute command before pip install
Message-ID: <f57b1dc8-9a0a-a563-5daa-6fc2f4b2d817@freakspot.net>

I need to execute a command automatically when running `pip install` to 
solve https://notabug.org/jorgesumle/boot-em-all/issues/1

I need to do that to compile the translation files. I found that 
overriding the `setuptools.command.install` makes it work with `python3 
setup.py install`, but I want it to work with pip as well. Any advice or 
think I overlooked? Is there a clean or recommended way to do this?

The whole code is free software, so you can check my `setup.py` file. 
The repository can be cloned executing `git clone 
https://notabug.org/jorgesumle/boot-em-all`.


From xiaojun.gou at nnct-nsn.com  Wed Apr 11 05:53:25 2018
From: xiaojun.gou at nnct-nsn.com (xiaojun.gou at nnct-nsn.com)
Date: Wed, 11 Apr 2018 17:53:25 +0800
Subject: [Distutils] setuptools package rpm issue
Message-ID: <2018041117532494923333@nnct-nsn.com>

hi?
    When i use the latest python version 3.6.5 to package the setuptools version 39.0.1 to rpm,the os is readhat 6.5.i have some problem.
    I use blow command to package it:
python3 setup.py bdist_rpm   --requires "Python3-nsn" --no-autoreq --packager "xiaojun.gou at nnct-nsn.com" --binary-only

 Then the error occured,the error messages is like this:
Processing files: setuptools-39.0.1.post20180411-1.noarch
error: Two files on one line: /usr/local/python3/lib/python3.6/site-packages/setuptools/script
error: File must begin with "/": (dev).tmpl
error: Two files on one line: /usr/local/python3/lib/python3.6/site-packages/setuptools/command/launcher
error: File must begin with "/": manifest.xml


RPM build errors:
    Two files on one line: /usr/local/python3/lib/python3.6/site-packages/setuptools/script
    File must begin with "/": (dev).tmpl
    Two files on one line: /usr/local/python3/lib/python3.6/site-packages/setuptools/command/launcher
    File must begin with "/": manifest.xml
error: command 'rpmbuild' failed with exit status 1

 I search the internet,and found this url:https://stackoverflow.com/questions/26718001/cannot-create-setuptools-rpm-error-two-files-on-one-line# . I followed it ,and found the above two files in the ./build/bdist.linux-x86_64/rpm/BUILD/setuptools-39.0.1.post20180411/INSTALLED_FILES file,there are spaces.
 Can you fix it?
    

Email:xiaojun.gou at nnct-nsn.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/e910ba33/attachment.html>

From pradyunsg at gmail.com  Wed Apr 11 12:32:50 2018
From: pradyunsg at gmail.com (Pradyun Gedam)
Date: Wed, 11 Apr 2018 16:32:50 +0000
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
Message-ID: <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>

On Tue, 10 Apr 2018, 05:17 Chris Jerdonek, <chris.jerdonek at gmail.com> wrote:

> On the pypa-dev Google group, a suggestion was raised about giving pip
> a way to communicate extra info to users.
>
> This was during a thread started by Matthew Brett about pip breaking
> for certain macOS users due to certain TLS changes ("Impending silent
> breakage of pip / macOS likely to cause severe confusion"). Donald
> said this behavior is governed by PEP 503 and that the topic was best
> discussed on distutils-sig:
> https://groups.google.com/d/msg/pypa-dev/Oz6SGA7gefo/RRXQBQSBBAAJ
> so I'm raising the suggestion here to continue the discussion.
>
> One of Donald's comments in response to the idea (and that occurred to
> me too and that I agree with) is that providing a way to communicate
> messages to users introduces another possible avenue for attack.
>
> A possible middle-ground could be to hard-code a message in pip. Pip
> could display the message in certain circumstances, e.g. in response
> to certain types of failures. For example, the message could tell
> users to check a certain URL maintained by PyPA for further
> information / possible announcements.
>
> What do people think?
>

I like the idea.

I think linking to a location where we can make informative comments would
be a good idea ? ideally where we can show announcements reverse
chronologically.

I don?t know how relevant they are but scenarios where this would help,
that come to my mind are:

- Status Page: "pypi.org is undergoing an incident and installations may
fail. You can find more information at status.python.org."
- Major Features: for things like PEP 517 when it's released. "There's
news. Have a look at pypi.org/news" or something like that.


> --


> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/41dbe868/attachment.html>

From p.f.moore at gmail.com  Wed Apr 11 13:18:30 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 11 Apr 2018 18:18:30 +0100
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
Message-ID: <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>

On 11 April 2018 at 17:32, Pradyun Gedam <pradyunsg at gmail.com> wrote:
> On Tue, 10 Apr 2018, 05:17 Chris Jerdonek, <chris.jerdonek at gmail.com> wrote:
[...]
>> A possible middle-ground could be to hard-code a message in pip. Pip
>> could display the message in certain circumstances, e.g. in response
>> to certain types of failures. For example, the message could tell
>> users to check a certain URL maintained by PyPA for further
>> information / possible announcements.
>>
>> What do people think?
>
>
> I like the idea.
>
> I think linking to a location where we can make informative comments would
> be a good idea ? ideally where we can show announcements reverse
> chronologically.
>
> I don?t know how relevant they are but scenarios where this would help, that
> come to my mind are:
>
> - Status Page: "pypi.org is undergoing an incident and installations may
> fail. You can find more information at status.python.org."

For HTTP type responses, which is what I understood Chris' question to
be about, this seems like a good approach to me - the index can supply
a response that triggers pip to report a message. "The index XXX
reported an issue - for more information see XXX/status". That would
need a PEP 503 change to say that an index can trigger this message by
sending a certain response code, and that if an index does send that
code, it must provide additional information at its /status page.

> - Major Features: for things like PEP 517 when it's released. "There's news.
> Have a look at pypi.org/news" or something like that.

For these, I was thinking about this in the context of how we announce
releases like pip 10. Maybe something like this would better fit as an
addition to the pip selfcheck code - so that as well as checking for a
newer version, pip would also check for a "Message of the day" at a
known URL and display it if there is one. That gives us a way to
announce releases or betas, or upcoming deprecations, in a way that
reaches every pip user (at least every one who's connected to the
internet!) It's a bit intrusive, so I think it's critical that we use
it sparingly, but it would be good to have at least some channel that
reaches everyone. I don't think it's something we'd want to use for
transient issues like pypi outages, for instance.

Paul

From jwodder at gmail.com  Wed Apr 11 13:35:06 2018
From: jwodder at gmail.com (John Thorvald Wodder II)
Date: Wed, 11 Apr 2018 13:35:06 -0400
Subject: [Distutils] Execute command before pip install
In-Reply-To: <f57b1dc8-9a0a-a563-5daa-6fc2f4b2d817@freakspot.net>
References: <f57b1dc8-9a0a-a563-5daa-6fc2f4b2d817@freakspot.net>
Message-ID: <959F04EF-9D5A-4E67-84D1-BECC29A28373@gmail.com>

> On 2018 Apr 11, at 06:55, Jorge Maldonado Ventura <jorgesumle at freakspot.net> wrote:
> 
> I need to execute a command automatically when running `pip install` to solve https://notabug.org/jorgesumle/boot-em-all/issues/1
> 
> I need to do that to compile the translation files. I found that overriding the `setuptools.command.install` makes it work with `python3 setup.py install`, but I want it to work with pip as well. Any advice or think I overlooked? Is there a clean or recommended way to do this?
> 
> The whole code is free software, so you can check my `setup.py` file. The repository can be cloned executing `git clone https://notabug.org/jorgesumle/boot-em-all`.

This can't be done.  `pip install` installs from wheel (.whl) files, and that installation process currently (and, I believe, by design) has no provision for running arbitrary code.  You have two options:

1. Extend the `setup.py bdist_wheel` command to compile & bundle the translation files as part of building the wheel.  I personally don't know how to do this, but I believe the process is somewhat similar to extending the `setup.py install` command.  Note that if the compiled translation files are architecture-dependent, you'll also need to add the appropriate tags to the wheel.

2. Give your library a `boot_em_all_compile_translations` command for compiling the translation files, which the user must then run manually after installation.

From brett at python.org  Wed Apr 11 13:54:32 2018
From: brett at python.org (Brett Cannon)
Date: Wed, 11 Apr 2018 17:54:32 +0000
Subject: [Distutils] Execute command before pip install
In-Reply-To: <959F04EF-9D5A-4E67-84D1-BECC29A28373@gmail.com>
References: <f57b1dc8-9a0a-a563-5daa-6fc2f4b2d817@freakspot.net>
 <959F04EF-9D5A-4E67-84D1-BECC29A28373@gmail.com>
Message-ID: <CAP1=2W6b1dc=3ziqofxjnZRsTf=EV5ed7gmh0UyoUqHMZz7+4g@mail.gmail.com>

On Wed, 11 Apr 2018 at 10:36 John Thorvald Wodder II <jwodder at gmail.com>
wrote:

> > On 2018 Apr 11, at 06:55, Jorge Maldonado Ventura <
> jorgesumle at freakspot.net> wrote:
> >
> > I need to execute a command automatically when running `pip install` to
> solve https://notabug.org/jorgesumle/boot-em-all/issues/1
> >
> > I need to do that to compile the translation files. I found that
> overriding the `setuptools.command.install` makes it work with `python3
> setup.py install`, but I want it to work with pip as well. Any advice or
> think I overlooked? Is there a clean or recommended way to do this?
> >
> > The whole code is free software, so you can check my `setup.py` file.
> The repository can be cloned executing `git clone
> https://notabug.org/jorgesumle/boot-em-all`
> <https://notabug.org/jorgesumle/boot-em-all>.
>
> This can't be done.  `pip install` installs from wheel (.whl) files, and
> that installation process currently (and, I believe, by design) has no
> provision for running arbitrary code.  You have two options:
>

Yep, it's by design to make installation as fast as copying some files from
a zip file.


>
> 1. Extend the `setup.py bdist_wheel` command to compile & bundle the
> translation files as part of building the wheel.  I personally don't know
> how to do this, but I believe the process is somewhat similar to extending
> the `setup.py install` command.  Note that if the compiled translation
> files are architecture-dependent, you'll also need to add the appropriate
> tags to the wheel.
>
> 2. Give your library a `boot_em_all_compile_translations` command for
> compiling the translation files, which the user must then run manually
> after installation.
>
>
Another option is to look at PEP 517-compatible tools like Enscons which
will give you more control over the wheel compilation process without
having to try to hack your way into Setuptools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/8e3059e7/attachment-0001.html>

From njs at pobox.com  Wed Apr 11 14:31:56 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 11 Apr 2018 18:31:56 +0000
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
Message-ID: <CAPJVwBmAFtqCS6Ja8aQdvWngAXEBx272_AkQrv3qtyzj99iqTw@mail.gmail.com>

On Mon, Apr 9, 2018, 16:47 Chris Jerdonek <chris.jerdonek at gmail.com> wrote:

>
> One of Donald's comments in response to the idea (and that occurred to
> me too and that I agree with) is that providing a way to communicate
> messages to users introduces another possible avenue for attack.


I agree that this is worth thinking about, but having thought about it I'm
having trouble coming up with a threat model where it creates additional
exposure?

If someone takes over package distribution, that's obviously a far more
serious problem. A messaging mechanism could amplify such an attack by
encouraging people to install the compromised packages ? but pip's existing
check for new pip versions can also do that. Or if we have a mechanism for
securing package updates, like TUF, then presumably we can use it to
protect the MOTD as well?

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/ee879f48/attachment.html>

From p.f.moore at gmail.com  Wed Apr 11 17:01:09 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 11 Apr 2018 22:01:09 +0100
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
 <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
 <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>
Message-ID: <CACac1F_P7OdiwjRGC5mmG4KgF+4=wd0UeeNXoyZEYmYw2_1+_Q@mail.gmail.com>

On 11 April 2018 at 20:16, Dwight Hubbard <dhubbard at oath.com> wrote:
> It would be useful as well for sites that run their own mirror
> infrastructure to be able to add motd text to the pip commands as well.
>
> However I don't think this should be implemented via the response code from
> a call to some rest api.  It would be trivial to proxy the call to a
> different location and send a different message.  Any implementation would
> need some way to sign and verify the message as authentic.

-1 on explicit signing and verification of messages. The
infrastructure needed for that is more than the feature warrants.

HTTPS access to the index server is fundamental to pip - if an
attacker can subvert that, they don't need to mess with a message,
they can just replace packages. So I don't see that displaying a
message that's available from that same index server is an additional
vulnerability, surely? But I'm not a security expert - I'd defer to
someone like Donald to comment on the security aspects of any proposal
here.

Paul

From sh at changeset.nyc  Wed Apr 11 22:30:49 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Wed, 11 Apr 2018 22:30:49 -0400
Subject: [Distutils] Summary of PyPI overhaul in new LWN article
Message-ID: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>

Today, LWN published my new article "A new package index for Python".
https://lwn.net/Articles/751458/ In it, I discuss security, policy, UX
and developer experience changes in the 15+ years since PyPI's founding,
new features (and deprecated old features) in Warehouse, and future
plans. Plus: screenshots!

If you aren't already an LWN subscriber, you can use this subscriber
link for the next week to read the article despite the LWN paywall.
https://lwn.net/SubscriberLink/751458/81b2759e7025d6b9/

This summary should help occasional Python programmers -- and frequent
Pythonists who don't follow packaging/distro discussions closely --
understand why a new application is necessary, what's new, what features
are going away, and what to expect in the near future. I also hope it
catches the attention of downstreams that ought to migrate.

-- 
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
https://changeset.nyc

From sandro at e-den.it  Thu Apr 12 07:14:18 2018
From: sandro at e-den.it (Alessandro Dentella)
Date: Thu, 12 Apr 2018 13:14:18 +0200
Subject: [Distutils] wierd namespaces: nspkh.pth makes a package builtin
Message-ID: <20180412111418.GA16461@bluff.e-den.it>

Hi,


I'm trying to debug a complex situazion in which a *nspkg.pth file
creates a builtin package that brakes the import in a uwsgi process.

In this case I'm still working with Python2.7.

To be sure the package is correct I started with an "almost empty" one
(whose content is shown below) and I have this strage behaviour:
if I install using 'python setup.py install' everithing is ok, if I
install with pip the namespace seems a builtin:

   root at argo-stretch:/tmp/jmb.vega# python setup.py install
   ...
   root at argo-stretch:/tmp/jmb.vega# python -c 'import jmb; print(jmb)'
   <module 'jmb' from '/usr/local/lib/python2.7/dist-packages/jmb.vega-0.1-py2.7.egg/jmb/__init__.pyc'>

In this case the file 'jmb.vega-0.1-nspkg.pth' is NOT created
and the egg is added to 'easy-install.pth'

When doing the installation with pip

   root at argo-stretch:/tmp/jmb.vega# pip install .
   Processing /tmp/jmb.vega
   Requirement already satisfied: setuptools in /usr/lib/python2.7/dist-packages (from jmb.vega==0.1)
   Installing collected packages: jmb.vega
     Running setup.py install for jmb.vega ... done
   Successfully installed jmb.vega-0.1

the file 'jmb.tools-0.7-py2.7-nspkg.pth' is created and the modules
seems a built-in

   root at argo-stretch:/tmp/jmb.vega# (cd ; python -c 'import jmb; print(jmb)')
   <module 'jmb' (built-in)>

In the real case this is enought to break the import system of any
call to namespace 'jmb'.

the test package is

   jmb.vega/
   ??? jmb
   ?   ??? __init__.py
   ?   ??? vega
   ?       ??? __init__.py
   ??? setup.py


sandro at bluff:/tmp/jmb.vega$ cat setup.py
from setuptools import setup, find_packages


setup(
    name='jmb.vega',
    namespace_packages=['jmb'],
    version="0.1",
    description='Test package',
    author='Alessandro Dentella',
    packages=find_packages(exclude=['tests', 'tests.*']),
    platforms='any',
    zip_safe=False,
    install_requires=[
        'setuptools',
    ],
)

While __init__ in jmb is:

sandro at bluff:/tmp/jmb.vega$ cat jmb/__init__.py
__import__('pkg_resources').declare_namespace(__name__)


What's wrong with the configuration?
Why pip makes it a builtin package?

thanks in advance
sandro
*:-)

--
Sandro Dentella  *:-)
http://trepalchi.it                Il portale degli artisti

http://www.reteisi.org             Soluzioni libere per le scuole
http://sqlkit.argolinux.org        SQLkit home page - PyGTK/python/sqlalchemy

From ncoghlan at gmail.com  Thu Apr 12 07:54:25 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Apr 2018 21:54:25 +1000
Subject: [Distutils] PEP 571: Any further manylinux2010 concerns or
 questions?
In-Reply-To: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
References: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
Message-ID: <CADiSq7f6OqETp25bf2=1BO0ya-CA9ZTUJ2K6dsHxaOCU=NfuiA@mail.gmail.com>

On 30 March 2018 at 20:46, Nick Coghlan <ncoghlan at gmail.com> wrote:
> PEP link: https://www.python.org/dev/peps/pep-0571/
>
> Thomas Kluyver has amended Mark Williams's PEP 571 to address the
> concerns & questions raised in the previous thread:
>
> * manylinux2 -> manylinux2010:
> https://github.com/python/peps/commit/70cbfda06534aedd6372f489090fdc8e1062de6e#diff-ed6b6d5f928c15489fc02dca72f4b519
> * using glibc 2.12 as a compatibility marker:
> https://github.com/python/peps/commit/d43b984e021eddc11bdbc36863c5c285b473f8a7#diff-ed6b6d5f928c15489fc02dca72f4b519
>
> (We also dropped a potentially misleading aside that could be taken as
> implying inaccurate limitations on Anaconda platform compatibility)
>
> As I expect quite a few folks will be busy for the Easter weekend, I'm
> planning to accept the PEP a week from next Monday (i.e on April 9th)
> if no new concerns or objections are raised between now and then :)

With one small amendment [1] to appropriately credit Geoffrey Thomas
and to provide a reference link for CalVer, I'm happy to report that
I'm accepting the manylinux2010 specification :)

With any luck, the switch to CalVer in the naming scheme will also
lower the barriers for folks interested in defining a manylinux
variant that offers a new enough ABI baseline that it can support
ppc64le and aarch64 in addition to x86_64. (That will still need a
separate PEP to over the specifics, though)

Regards,
Nick.

[1] https://github.com/python/peps/pull/612/files

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Thu Apr 12 08:10:01 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Apr 2018 22:10:01 +1000
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CACac1F_P7OdiwjRGC5mmG4KgF+4=wd0UeeNXoyZEYmYw2_1+_Q@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
 <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
 <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>
 <CACac1F_P7OdiwjRGC5mmG4KgF+4=wd0UeeNXoyZEYmYw2_1+_Q@mail.gmail.com>
Message-ID: <CADiSq7dsgV303mQZFHbMs=7WxnKZHRWjOZOpwbObwigvOOreZg@mail.gmail.com>

On 12 April 2018 at 07:01, Paul Moore <p.f.moore at gmail.com> wrote:
> HTTPS access to the index server is fundamental to pip - if an
> attacker can subvert that, they don't need to mess with a message,
> they can just replace packages. So I don't see that displaying a
> message that's available from that same index server is an additional
> vulnerability, surely? But I'm not a security expert - I'd defer to
> someone like Donald to comment on the security aspects of any proposal
> here.

Right now it doesn't create any additional vulnerabilities, since
we're relying primarily on HTTPS for PyPI -> installer security.

However, that changes once PEP 458 gets implemented, as that will
switch the primary package level security mechanism over to TUF, which
includes a range of mechanisms designed to detect tampering with the
link to PyPI (including freeze attacks that keep you from checking for
new packages, or attempting to lie about which versions are
available).

So the scenario we want to avoid is one where an attacker can present
a notice that says "Please ignore that scary security warning your
installer is giving you, we're having an issue with the metadata
generation process on the server. To resolve the problem, please force
upgrade pip".

That's a solvable problem (e.g. only check for the MOTD *after*
successfully retrieving a valid metadata file), but it's still
something to take into account.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From dhubbard at oath.com  Wed Apr 11 15:16:29 2018
From: dhubbard at oath.com (Dwight Hubbard)
Date: Wed, 11 Apr 2018 12:16:29 -0700
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
 <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
Message-ID: <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>

It would be useful as well for sites that run their own mirror
infrastructure to be able to add motd text to the pip commands as well.

However I don't think this should be implemented via the response code from
a call to some rest api.  It would be trivial to proxy the call to a
different location and send a different message.  Any implementation would
need some way to sign and verify the message as authentic.

On Wed, Apr 11, 2018 at 10:18 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 11 April 2018 at 17:32, Pradyun Gedam <pradyunsg at gmail.com> wrote:
> > On Tue, 10 Apr 2018, 05:17 Chris Jerdonek, <chris.jerdonek at gmail.com>
> wrote:
> [...]
> >> A possible middle-ground could be to hard-code a message in pip. Pip
> >> could display the message in certain circumstances, e.g. in response
> >> to certain types of failures. For example, the message could tell
> >> users to check a certain URL maintained by PyPA for further
> >> information / possible announcements.
> >>
> >> What do people think?
> >
> >
> > I like the idea.
> >
> > I think linking to a location where we can make informative comments
> would
> > be a good idea ? ideally where we can show announcements reverse
> > chronologically.
> >
> > I don?t know how relevant they are but scenarios where this would help,
> that
> > come to my mind are:
> >
> > - Status Page: "pypi.org is undergoing an incident and installations may
> > fail. You can find more information at status.python.org."
>
> For HTTP type responses, which is what I understood Chris' question to
> be about, this seems like a good approach to me - the index can supply
> a response that triggers pip to report a message. "The index XXX
> reported an issue - for more information see XXX/status". That would
> need a PEP 503 change to say that an index can trigger this message by
> sending a certain response code, and that if an index does send that
> code, it must provide additional information at its /status page.
>
> > - Major Features: for things like PEP 517 when it's released. "There's
> news.
> > Have a look at pypi.org/news" or something like that.
>
> For these, I was thinking about this in the context of how we announce
> releases like pip 10. Maybe something like this would better fit as an
> addition to the pip selfcheck code - so that as well as checking for a
> newer version, pip would also check for a "Message of the day" at a
> known URL and display it if there is one. That gives us a way to
> announce releases or betas, or upcoming deprecations, in a way that
> reaches every pip user (at least every one who's connected to the
> internet!) It's a bit intrusive, so I think it's critical that we use
> it sparingly, but it would be good to have at least some channel that
> reaches everyone. I don't think it's something we'd want to use for
> transient issues like pypi outages, for instance.
>
> Paul
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Dwight Hubbard
Python Language Guy
M: 408-646-9444
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180411/5d0ef0cf/attachment.html>

From vvkm134 at gmail.com  Thu Apr 12 05:08:36 2018
From: vvkm134 at gmail.com (VIVEK MATALIA)
Date: Thu, 12 Apr 2018 14:38:36 +0530
Subject: [Distutils] (no subject)
Message-ID: <5acf2216.4558620a.ffa05.349f@mx.google.com>


How to download graphics zelle?

Sent from Mail for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/f7e33144/attachment.html>

From njs at pobox.com  Thu Apr 12 08:26:27 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 12 Apr 2018 12:26:27 +0000
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CADiSq7dsgV303mQZFHbMs=7WxnKZHRWjOZOpwbObwigvOOreZg@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
 <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
 <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>
 <CACac1F_P7OdiwjRGC5mmG4KgF+4=wd0UeeNXoyZEYmYw2_1+_Q@mail.gmail.com>
 <CADiSq7dsgV303mQZFHbMs=7WxnKZHRWjOZOpwbObwigvOOreZg@mail.gmail.com>
Message-ID: <CAPJVwBk1z3wruyEwFQ1cywQyD+4O3ptHbeFB94DtZQ4VfRs0Eg@mail.gmail.com>

>From the TUF perspective it seems like it would be straightforward to make
the MOTD a "package", whose "contents" is the MOTD text, and that we
"upgrade" it to get the latest text before displaying anything.

-n

On Thu, Apr 12, 2018, 05:10 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 12 April 2018 at 07:01, Paul Moore <p.f.moore at gmail.com> wrote:
> > HTTPS access to the index server is fundamental to pip - if an
> > attacker can subvert that, they don't need to mess with a message,
> > they can just replace packages. So I don't see that displaying a
> > message that's available from that same index server is an additional
> > vulnerability, surely? But I'm not a security expert - I'd defer to
> > someone like Donald to comment on the security aspects of any proposal
> > here.
>
> Right now it doesn't create any additional vulnerabilities, since
> we're relying primarily on HTTPS for PyPI -> installer security.
>
> However, that changes once PEP 458 gets implemented, as that will
> switch the primary package level security mechanism over to TUF, which
> includes a range of mechanisms designed to detect tampering with the
> link to PyPI (including freeze attacks that keep you from checking for
> new packages, or attempting to lie about which versions are
> available).
>
> So the scenario we want to avoid is one where an attacker can present
> a notice that says "Please ignore that scary security warning your
> installer is giving you, we're having an issue with the metadata
> generation process on the server. To resolve the problem, please force
> upgrade pip".
>
> That's a solvable problem (e.g. only check for the MOTD *after*
> successfully retrieving a valid metadata file), but it's still
> something to take into account.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/7f3f79d5/attachment-0001.html>

From trishank.kuppusamy at datadoghq.com  Thu Apr 12 11:58:09 2018
From: trishank.kuppusamy at datadoghq.com (Trishank Kuppusamy)
Date: Thu, 12 Apr 2018 11:58:09 -0400
Subject: [Distutils] Summary of PyPI overhaul in new LWN article
In-Reply-To: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>
References: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>
Message-ID: <CAEd-exP_2jJLYc5na_q-A1bQr+Kfh-ZYsa00OKsa+8cUq=iHag@mail.gmail.com>

On Wed, Apr 11, 2018 at 10:30 PM, Sumana Harihareswara <sh at changeset.nyc>
wrote:

> Today, LWN published my new article "A new package index for Python".
> https://lwn.net/Articles/751458/ In it, I discuss security, policy, UX
> and developer experience changes in the 15+ years since PyPI's founding,
> new features (and deprecated old features) in Warehouse, and future
> plans. Plus: screenshots!
>
> If you aren't already an LWN subscriber, you can use this subscriber
> link for the next week to read the article despite the LWN paywall.
> https://lwn.net/SubscriberLink/751458/81b2759e7025d6b9/


Thanks for the summary, and all your hard work, Sumana :)

Happy to see this bit about TUF in future horizons:

Warehouse's signature handling demonstrates a shift in Python's thinking
> regarding key management and package signatures. Ideally, package users,
> software distributors, and package distribution tools would regularly use
> signatures to verify Python package integrity. For the most part, however,
> they don't, and there are major infrastructural barriers to them
> effectively doing so. Therefore, GPG/PGP signatures for packages are no
> longer visible in PyPI's web interface. Project maintainers can still
> attach signatures to their release uploads, and those signatures still
> appear in the Simple Project API as described in PEP 503. Stufft has made
> no secret of his opinion that "package signing is not the Holy Grail";
> current discussion among packaging-tools developers leans toward removing
> signing features from another part of the Python packaging ecology (the
> wheel library) and working toward implementing The Update Framework
> instead. Relatedly, Warehouse, unlike legacy PyPI, does not provide an
> interface for users to manage GPG or SSH public keys.


 We would love to help with this efforts any way we can.

-- 
curl https://keybase.io/trishankdatadog/pgp_keys.asc | gpg --import
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/a8331094/attachment.html>

From jcappos at nyu.edu  Thu Apr 12 12:12:36 2018
From: jcappos at nyu.edu (Justin Cappos)
Date: Thu, 12 Apr 2018 12:12:36 -0400
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CAPJVwBk1z3wruyEwFQ1cywQyD+4O3ptHbeFB94DtZQ4VfRs0Eg@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
 <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
 <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>
 <CACac1F_P7OdiwjRGC5mmG4KgF+4=wd0UeeNXoyZEYmYw2_1+_Q@mail.gmail.com>
 <CADiSq7dsgV303mQZFHbMs=7WxnKZHRWjOZOpwbObwigvOOreZg@mail.gmail.com>
 <CAPJVwBk1z3wruyEwFQ1cywQyD+4O3ptHbeFB94DtZQ4VfRs0Eg@mail.gmail.com>
Message-ID: <CAMVss_rXdY5DAdUe97uDLP-VN7GXJiqV_rxq7P4mdAZUEKPkjA@mail.gmail.com>

FYI: TUF has a custom metadata field in the targets metadata that could
potentially be used for this purpose.  We can explain more if there is
interest...

On Thu, Apr 12, 2018 at 8:26 AM, Nathaniel Smith <njs at pobox.com> wrote:

> From the TUF perspective it seems like it would be straightforward to make
> the MOTD a "package", whose "contents" is the MOTD text, and that we
> "upgrade" it to get the latest text before displaying anything.
>
> -n
>
> On Thu, Apr 12, 2018, 05:10 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 12 April 2018 at 07:01, Paul Moore <p.f.moore at gmail.com> wrote:
>> > HTTPS access to the index server is fundamental to pip - if an
>> > attacker can subvert that, they don't need to mess with a message,
>> > they can just replace packages. So I don't see that displaying a
>> > message that's available from that same index server is an additional
>> > vulnerability, surely? But I'm not a security expert - I'd defer to
>> > someone like Donald to comment on the security aspects of any proposal
>> > here.
>>
>> Right now it doesn't create any additional vulnerabilities, since
>> we're relying primarily on HTTPS for PyPI -> installer security.
>>
>> However, that changes once PEP 458 gets implemented, as that will
>> switch the primary package level security mechanism over to TUF, which
>> includes a range of mechanisms designed to detect tampering with the
>> link to PyPI (including freeze attacks that keep you from checking for
>> new packages, or attempting to lie about which versions are
>> available).
>>
>> So the scenario we want to avoid is one where an attacker can present
>> a notice that says "Please ignore that scary security warning your
>> installer is giving you, we're having an issue with the metadata
>> generation process on the server. To resolve the problem, please force
>> upgrade pip".
>>
>> That's a solvable problem (e.g. only check for the MOTD *after*
>> successfully retrieving a valid metadata file), but it's still
>> something to take into account.
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/75ee8f4c/attachment.html>

From wes.turner at gmail.com  Thu Apr 12 13:10:41 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Thu, 12 Apr 2018 13:10:41 -0400
Subject: [Distutils] providing a way for pip to communicate extra info
 to users
In-Reply-To: <CAMVss_rXdY5DAdUe97uDLP-VN7GXJiqV_rxq7P4mdAZUEKPkjA@mail.gmail.com>
References: <CAOTb1wcK9RBRHGmpSV77aMYqTHp73r2DQi5_dPCJrPzxUZ4auQ@mail.gmail.com>
 <CAPA-EqupPuozqL_g22Lu+ALUpkPJu6mqxfKET9Cn-AwhUsvdYg@mail.gmail.com>
 <CACac1F_RdMnbjJ-K1b-2b5LO28R5Wbgh-f-bWtjemqOC1=_gRQ@mail.gmail.com>
 <CAE5BUWk4fJXHCWCR+7n5q7m+N9_4v8BmX1JUNk_esgan6h1DYA@mail.gmail.com>
 <CACac1F_P7OdiwjRGC5mmG4KgF+4=wd0UeeNXoyZEYmYw2_1+_Q@mail.gmail.com>
 <CADiSq7dsgV303mQZFHbMs=7WxnKZHRWjOZOpwbObwigvOOreZg@mail.gmail.com>
 <CAPJVwBk1z3wruyEwFQ1cywQyD+4O3ptHbeFB94DtZQ4VfRs0Eg@mail.gmail.com>
 <CAMVss_rXdY5DAdUe97uDLP-VN7GXJiqV_rxq7P4mdAZUEKPkjA@mail.gmail.com>
Message-ID: <CACfEFw8-+7Jp4tYF56KeehHm8xgTKvsYzirKQj2eNXB88M6n_w@mail.gmail.com>

A MOTD from anything but a signed package would be user-supplied input.
Shell/terminal command ^[escaping would be necessary:
https://stackoverflow.com/questions/6534556/how-to-remove-and-all-of-the-escape-sequences-in-a-file-using-linux-shell-sc

Impact:

Are additional requests and variable messages really necessary? Can static
error messages simply say 'check /news for more information'? (thus saving:
millions of requests per year and additional MOTD package signing overhead
and bandwidth)?



On Thursday, April 12, 2018, Justin Cappos <jcappos at nyu.edu> wrote:

> FYI: TUF has a custom metadata field in the targets metadata that could
> potentially be used for this purpose.  We can explain more if there is
> interest...
>
> On Thu, Apr 12, 2018 at 8:26 AM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> From the TUF perspective it seems like it would be straightforward to
>> make the MOTD a "package", whose "contents" is the MOTD text, and that we
>> "upgrade" it to get the latest text before displaying anything.
>>
>> -n
>>
>> On Thu, Apr 12, 2018, 05:10 Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 12 April 2018 at 07:01, Paul Moore <p.f.moore at gmail.com> wrote:
>>> > HTTPS access to the index server is fundamental to pip - if an
>>> > attacker can subvert that, they don't need to mess with a message,
>>> > they can just replace packages. So I don't see that displaying a
>>> > message that's available from that same index server is an additional
>>> > vulnerability, surely? But I'm not a security expert - I'd defer to
>>> > someone like Donald to comment on the security aspects of any proposal
>>> > here.
>>>
>>> Right now it doesn't create any additional vulnerabilities, since
>>> we're relying primarily on HTTPS for PyPI -> installer security.
>>>
>>> However, that changes once PEP 458 gets implemented, as that will
>>> switch the primary package level security mechanism over to TUF, which
>>> includes a range of mechanisms designed to detect tampering with the
>>> link to PyPI (including freeze attacks that keep you from checking for
>>> new packages, or attempting to lie about which versions are
>>> available).
>>>
>>> So the scenario we want to avoid is one where an attacker can present
>>> a notice that says "Please ignore that scary security warning your
>>> installer is giving you, we're having an issue with the metadata
>>> generation process on the server. To resolve the problem, please force
>>> upgrade pip".
>>>
>>> That's a solvable problem (e.g. only check for the MOTD *after*
>>> successfully retrieving a valid metadata file), but it's still
>>> something to take into account.
>>>
>>> Cheers,
>>> Nick.
>>>
>>> --
>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/4365f769/attachment.html>

From wes.turner at gmail.com  Thu Apr 12 13:22:55 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Thu, 12 Apr 2018 13:22:55 -0400
Subject: [Distutils] Summary of PyPI overhaul in new LWN article
In-Reply-To: <CAEd-exP_2jJLYc5na_q-A1bQr+Kfh-ZYsa00OKsa+8cUq=iHag@mail.gmail.com>
References: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>
 <CAEd-exP_2jJLYc5na_q-A1bQr+Kfh-ZYsa00OKsa+8cUq=iHag@mail.gmail.com>
Message-ID: <CACfEFw_NCa-4oJdGRr1Vyoqn8vytWmoYByWLnTqLS9YXjr5urA@mail.gmail.com>

>From "TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519"

https://mail.python.org/pipermail/distutils-sig/2018-March/032081.html :

> Are there pypa/warehouse github issues for implementing the TUF trust
root support in warehouse; and client support in pip (or a module that pip
and other tools can use)?

Read and review these PEPs:

"PEP 458 -- Surviving a Compromise of PyPI"
https://www.python.org/dev/peps/pep-0458/"

"PEP 480 -- Surviving a Compromise of PyPI: The Maximum Security Model"
https://www.python.org/dev/peps/pep-0480/

On Thursday, April 12, 2018, Trishank Kuppusamy <
trishank.kuppusamy at datadoghq.com> wrote:

> On Wed, Apr 11, 2018 at 10:30 PM, Sumana Harihareswara <sh at changeset.nyc>
> wrote:
>
>> Today, LWN published my new article "A new package index for Python".
>> https://lwn.net/Articles/751458/ In it, I discuss security, policy, UX
>> and developer experience changes in the 15+ years since PyPI's founding,
>> new features (and deprecated old features) in Warehouse, and future
>> plans. Plus: screenshots!
>>
>> If you aren't already an LWN subscriber, you can use this subscriber
>> link for the next week to read the article despite the LWN paywall.
>> https://lwn.net/SubscriberLink/751458/81b2759e7025d6b9/
>
>
> Thanks for the summary, and all your hard work, Sumana :)
>
> Happy to see this bit about TUF in future horizons:
>
> Warehouse's signature handling demonstrates a shift in Python's thinking
>> regarding key management and package signatures. Ideally, package users,
>> software distributors, and package distribution tools would regularly use
>> signatures to verify Python package integrity. For the most part, however,
>> they don't, and there are major infrastructural barriers to them
>> effectively doing so. Therefore, GPG/PGP signatures for packages are no
>> longer visible in PyPI's web interface. Project maintainers can still
>> attach signatures to their release uploads, and those signatures still
>> appear in the Simple Project API as described in PEP 503. Stufft has made
>> no secret of his opinion that "package signing is not the Holy Grail";
>> current discussion among packaging-tools developers leans toward removing
>> signing features from another part of the Python packaging ecology (the
>> wheel library) and working toward implementing The Update Framework
>> instead. Relatedly, Warehouse, unlike legacy PyPI, does not provide an
>> interface for users to manage GPG or SSH public keys.
>
>
>  We would love to help with this efforts any way we can.
>
> --
> curl https://keybase.io/trishankdatadog/pgp_keys.asc | gpg --import
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/f08130dd/attachment-0001.html>

From trishank.kuppusamy at datadoghq.com  Thu Apr 12 13:29:17 2018
From: trishank.kuppusamy at datadoghq.com (Trishank Kuppusamy)
Date: Thu, 12 Apr 2018 13:29:17 -0400
Subject: [Distutils] Summary of PyPI overhaul in new LWN article
In-Reply-To: <CACfEFw_NCa-4oJdGRr1Vyoqn8vytWmoYByWLnTqLS9YXjr5urA@mail.gmail.com>
References: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>
 <CAEd-exP_2jJLYc5na_q-A1bQr+Kfh-ZYsa00OKsa+8cUq=iHag@mail.gmail.com>
 <CACfEFw_NCa-4oJdGRr1Vyoqn8vytWmoYByWLnTqLS9YXjr5urA@mail.gmail.com>
Message-ID: <CAEd-exMcpR_3GzMKLrw4dAGecuB5Q7tjio7e-bBQc73VJoop-A@mail.gmail.com>

Hi Wes,

On Thu, Apr 12, 2018 at 1:22 PM, Wes Turner <wes.turner at gmail.com> wrote:

> > Are there pypa/warehouse github issues for implementing the TUF trust
> root support in warehouse; and client support in pip (or a module that pip
> and other tools can use)?
>

For client support in pip, we are discussing this patch with Donald Stufft:

https://github.com/pypa/pip/compare/release/9.0.3...trishankatdatadog:trishankatdatadog/9.0.3.tuf-in-toto

Happy to discuss more with anyone interested!

-- 
curl https://keybase.io/trishankdatadog/pgp_keys.asc | gpg --import
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180412/d08b0d56/attachment.html>

From niharika1883 at gmail.com  Fri Apr 13 07:00:47 2018
From: niharika1883 at gmail.com (Niharika Jakhar)
Date: Fri, 13 Apr 2018 13:00:47 +0200
Subject: [Distutils] Pip upgrade
Message-ID: <CABrCUu1nw+YugXPc+NtuSKpLvyYUWMvkAgK9pDW60rVNChPuBw@mail.gmail.com>

Hi
I am having troubles upgrading my pip.
terminal says:
You are using pip version 9.0.1, however version 9.0.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

I used the same command as mentioned but it keeps on repeating the same
lines.


python version: Python 2.7.12
pip version: pip 9.0.1

Kindly help me in this regard.

Thanking you in advance

Best Regards
NIHARIKA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180413/638d8e9d/attachment.html>

From ncoghlan at gmail.com  Fri Apr 13 08:17:57 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Apr 2018 22:17:57 +1000
Subject: [Distutils] Pip upgrade
In-Reply-To: <CABrCUu1nw+YugXPc+NtuSKpLvyYUWMvkAgK9pDW60rVNChPuBw@mail.gmail.com>
References: <CABrCUu1nw+YugXPc+NtuSKpLvyYUWMvkAgK9pDW60rVNChPuBw@mail.gmail.com>
Message-ID: <CADiSq7c76i8FtRh+fqtoHPT5AZzWkny3+tNyXqqen9NwUqu2oA@mail.gmail.com>

On 13 April 2018 at 21:00, Niharika Jakhar <niharika1883 at gmail.com> wrote:
> Hi
> I am having troubles upgrading my pip.
> terminal says:
> You are using pip version 9.0.1, however version 9.0.3 is available.
> You should consider upgrading via the 'pip install --upgrade pip' command.

Which operating system are you running? `pip` self upgrades on Windows
can be a bit odd, so "py -m pip install --upgrade pip" may work better
there.

If you're on an older version of Mac OS X, you may be affected by the
TLS issues there, and need to follow the instructions at
https://mail.python.org/pipermail/python-announce-list/2018-April/011885.html

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From niharika1883 at gmail.com  Fri Apr 13 09:02:29 2018
From: niharika1883 at gmail.com (Niharika Jakhar)
Date: Fri, 13 Apr 2018 13:02:29 +0000
Subject: [Distutils] Pip upgrade
In-Reply-To: <CADiSq7c76i8FtRh+fqtoHPT5AZzWkny3+tNyXqqen9NwUqu2oA@mail.gmail.com>
References: <CABrCUu1nw+YugXPc+NtuSKpLvyYUWMvkAgK9pDW60rVNChPuBw@mail.gmail.com>
 <CADiSq7c76i8FtRh+fqtoHPT5AZzWkny3+tNyXqqen9NwUqu2oA@mail.gmail.com>
Message-ID: <CABrCUu3S2O_Y2oqLfCyq9K_x88d+DpWB=6eu0KV927mM-4j3ew@mail.gmail.com>

Thank you for your reply. I am using LINUX.

On Fri 13 Apr, 2018, 14:17 Nick Coghlan, <ncoghlan at gmail.com> wrote:

> On 13 April 2018 at 21:00, Niharika Jakhar <niharika1883 at gmail.com> wrote:
> > Hi
> > I am having troubles upgrading my pip.
> > terminal says:
> > You are using pip version 9.0.1, however version 9.0.3 is available.
> > You should consider upgrading via the 'pip install --upgrade pip'
> command.
>
> Which operating system are you running? `pip` self upgrades on Windows
> can be a bit odd, so "py -m pip install --upgrade pip" may work better
> there.
>
> If you're on an older version of Mac OS X, you may be affected by the
> TLS issues there, and need to follow the instructions at
>
> https://mail.python.org/pipermail/python-announce-list/2018-April/011885.html
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180413/6abd5ef9/attachment.html>

From ncoghlan at gmail.com  Fri Apr 13 09:44:47 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Apr 2018 23:44:47 +1000
Subject: [Distutils] Pip upgrade
In-Reply-To: <CABrCUu3S2O_Y2oqLfCyq9K_x88d+DpWB=6eu0KV927mM-4j3ew@mail.gmail.com>
References: <CABrCUu1nw+YugXPc+NtuSKpLvyYUWMvkAgK9pDW60rVNChPuBw@mail.gmail.com>
 <CADiSq7c76i8FtRh+fqtoHPT5AZzWkny3+tNyXqqen9NwUqu2oA@mail.gmail.com>
 <CABrCUu3S2O_Y2oqLfCyq9K_x88d+DpWB=6eu0KV927mM-4j3ew@mail.gmail.com>
Message-ID: <CADiSq7dHsdBdYKH1P8eKU89EodmEF4mZgWkF-j8UfD3pPjsHUg@mail.gmail.com>

On 13 April 2018 at 23:02, Niharika Jakhar <niharika1883 at gmail.com> wrote:
> Thank you for your reply. I am using LINUX.

Ah, then that means the resoluation unfortunately be distro dependent :(

If you're using the distro provided pip or pip3 installation, then
you'll need to do a distro level package update to get the newer
version (assuming your distro has made the newer version available).

If you're using a user level installation, then you'll need to run
"python -m pip install --upgrade --user pip" to update the user level
pip installation for Python 2.

If you're using virtual environments, then I would have expected the
suggested command to work, but you'll need to run it in each affected
virtual environment.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From sh at changeset.nyc  Fri Apr 13 10:54:08 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Fri, 13 Apr 2018 10:54:08 -0400
Subject: [Distutils] please mark good first issues in your projects
Message-ID: <9d7ab821-7516-e2de-9c0c-ee22b8028e65@changeset.nyc>

Warehouse is attracting several newer contributors including people new
to open source, which is great. As Warehouse matures, we have fewer and
fewer easy small bugs *in the Python side* left. (So, we have more work
for new frontend contributors, and less for Pythonists.)

I'd love to refer these folks to other parts of the Python packaging and
distribution ecosystem so we can improve the whole toolchain. Right now
there are 29 open issues in PyPA projects on GitHub marked "good first
issue", 11 in Warehouse and most of the rest in pip:

https://github.com/issues?utf8=%E2%9C%93&q=user%3Apypa+is%3Aopen+label%3A%22good+first+issue%22+

I'm totally fine with giving new volunteers teensy tiny doc fix tasks,
"manually test this functionality" tasks, and "check whether this bug is
still reproducible" tasks, in case you want to write up some of those.
Here's a template we use to make good first issues in Warehouse, in case
you want to emulate it:
https://github.com/pypa/warehouse/issues/new?template=good-first-issue.md


**Good First Issue**: This issue is good for first time contributors. If
you've already contributed to Warehouse, please work on [another issue
without this
label](https://github.com/pypa/warehouse/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22good+first+issue%22)
instead. If there is not a corresponding pull request for this issue, it
is up for grabs. For directions for getting set up, see our [Getting
Started Guide](https://warehouse.pypa.io/development/getting-started/).
If you are working on this issue and have questions, please feel free to
ask them here, [`#pypa-dev` on
Freenode](https://webchat.freenode.net/?channels=%23pypa-dev), or the
[pypa-dev mailing list](https://groups.google.com/forum/#!forum/pypa-dev).


If your project isn't under https://github.com/pypa , but you want to
publicize your good first issues, reply to this thread? Thanks.

-- 
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
https://changeset.nyc

From nad at python.org  Fri Apr 13 11:27:05 2018
From: nad at python.org (Ned Deily)
Date: Fri, 13 Apr 2018 11:27:05 -0400
Subject: [Distutils] Pip upgrade
In-Reply-To: <CADiSq7dHsdBdYKH1P8eKU89EodmEF4mZgWkF-j8UfD3pPjsHUg@mail.gmail.com>
References: <CABrCUu1nw+YugXPc+NtuSKpLvyYUWMvkAgK9pDW60rVNChPuBw@mail.gmail.com>
 <CADiSq7c76i8FtRh+fqtoHPT5AZzWkny3+tNyXqqen9NwUqu2oA@mail.gmail.com>
 <CABrCUu3S2O_Y2oqLfCyq9K_x88d+DpWB=6eu0KV927mM-4j3ew@mail.gmail.com>
 <CADiSq7dHsdBdYKH1P8eKU89EodmEF4mZgWkF-j8UfD3pPjsHUg@mail.gmail.com>
Message-ID: <3B899425-0FC8-4311-BE37-E5864B0C7923@python.org>

On Apr 13, 2018, at 09:44, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 13 April 2018 at 23:02, Niharika Jakhar <niharika1883 at gmail.com> wrote:
>> Thank you for your reply. I am using LINUX.
> 
> Ah, then that means the resoluation unfortunately be distro dependent :(
> 
> If you're using the distro provided pip or pip3 installation, then
> you'll need to do a distro level package update to get the newer
> version (assuming your distro has made the newer version available).
> 
> If you're using a user level installation, then you'll need to run
> "python -m pip install --upgrade --user pip" to update the user level
> pip installation for Python 2.
> 
> If you're using virtual environments, then I would have expected the
> suggested command to work, but you'll need to run it in each affected
> virtual environment.

Upgrading pip may not help if the underlying problem is a version of the OpenSSL libraries that is too old.  Try adding -v to the pip install command to get more information:

pip install --upgrade -v pip

--
  Ned Deily
  nad at python.org -- []


From c at anthonyrisinger.com  Fri Apr 13 11:32:34 2018
From: c at anthonyrisinger.com (C Anthony Risinger)
Date: Fri, 13 Apr 2018 15:32:34 +0000
Subject: [Distutils] please mark good first issues in your projects
In-Reply-To: <9d7ab821-7516-e2de-9c0c-ee22b8028e65@changeset.nyc>
References: <9d7ab821-7516-e2de-9c0c-ee22b8028e65@changeset.nyc>
Message-ID: <CAGAVQTGaGOXwt86vGxkj-zbWX7GCvAhPnLn0rYjhBwZdthnDMg@mail.gmail.com>

Do these kind of issues ever linger on unreasonably, or do enough
voluneteers step up to keep them low? Do you expire that label after a few
months?

I don't have any feedback on your actual request, I'm mostly curious of the
process/interplay around feeding new users work without introduce excessive
delay or otherwise.

Thanks,

On Fri, Apr 13, 2018, 9:55 AM Sumana Harihareswara <sh at changeset.nyc> wrote:

> Warehouse is attracting several newer contributors including people new
> to open source, which is great. As Warehouse matures, we have fewer and
> fewer easy small bugs *in the Python side* left. (So, we have more work
> for new frontend contributors, and less for Pythonists.)
>
> I'd love to refer these folks to other parts of the Python packaging and
> distribution ecosystem so we can improve the whole toolchain. Right now
> there are 29 open issues in PyPA projects on GitHub marked "good first
> issue", 11 in Warehouse and most of the rest in pip:
>
>
> https://github.com/issues?utf8=%E2%9C%93&q=user%3Apypa+is%3Aopen+label%3A%22good+first+issue%22+
>
> I'm totally fine with giving new volunteers teensy tiny doc fix tasks,
> "manually test this functionality" tasks, and "check whether this bug is
> still reproducible" tasks, in case you want to write up some of those.
> Here's a template we use to make good first issues in Warehouse, in case
> you want to emulate it:
> https://github.com/pypa/warehouse/issues/new?template=good-first-issue.md
>
>
> **Good First Issue**: This issue is good for first time contributors. If
> you've already contributed to Warehouse, please work on [another issue
> without this
> label](
> https://github.com/pypa/warehouse/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22good+first+issue%22
> )
> instead. If there is not a corresponding pull request for this issue, it
> is up for grabs. For directions for getting set up, see our [Getting
> Started Guide](https://warehouse.pypa.io/development/getting-started/).
> If you are working on this issue and have questions, please feel free to
> ask them here, [`#pypa-dev` on
> Freenode](https://webchat.freenode.net/?channels=%23pypa-dev), or the
> [pypa-dev mailing list](https://groups.google.com/forum/#!forum/pypa-dev).
>
>
> If your project isn't under https://github.com/pypa , but you want to
> publicize your good first issues, reply to this thread? Thanks.
>
> --
> Sumana Harihareswara
> Warehouse project manager
> Changeset Consulting
> https://changeset.nyc
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180413/b03d4618/attachment.html>

From sh at changeset.nyc  Fri Apr 13 14:22:29 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Fri, 13 Apr 2018 14:22:29 -0400
Subject: [Distutils] please mark good first issues in your projects
In-Reply-To: <CAGAVQTGaGOXwt86vGxkj-zbWX7GCvAhPnLn0rYjhBwZdthnDMg@mail.gmail.com>
References: <9d7ab821-7516-e2de-9c0c-ee22b8028e65@changeset.nyc>
 <CAGAVQTGaGOXwt86vGxkj-zbWX7GCvAhPnLn0rYjhBwZdthnDMg@mail.gmail.com>
Message-ID: <798ec807-f15a-8b68-0e1a-c5d80c15debb@changeset.nyc>

In my experience (not just here but within Zulip, Wikimedia, Mailman,
and other projects), this depends on the project's maintainers.

If maintainers actively put the word out that a project is seeking new
volunteers, respond to new questions and patches within a few days, and
comment on finished issues to say "great! want another?", volunteers
work through the "good first issues" queue steadily and it needs regular
replenishment. It is worth taking a fresh look at the queue every month
or two to double-check whether any of the open issues labelled "good
first issue" are harder than they first appeared, then remove the label
with an explanatory comment.

(My further advice on stuff like this -- "How To Improve Bus Factor In
Your Open Source Project", "How to Teach And Include Volunteers who
Write Poor Patches", "Inclusive-Or: Hospitality in Bug Tracking", etc.
-- are at my resources page https://changeset.nyc/resources.html .)
-- 
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
https://changeset.nyc

On 04/13/2018 11:32 AM, C Anthony Risinger wrote:
> Do these kind of issues ever linger on unreasonably, or do enough
> voluneteers step up to keep them low? Do you expire that label after a few
> months?
> 
> I don't have any feedback on your actual request, I'm mostly curious of the
> process/interplay around feeding new users work without introduce excessive
> delay or otherwise.
> 
> Thanks,
> 
> On Fri, Apr 13, 2018, 9:55 AM Sumana Harihareswara <sh at changeset.nyc> wrote:
> 
>> Warehouse is attracting several newer contributors including people new
>> to open source, which is great. As Warehouse matures, we have fewer and
>> fewer easy small bugs *in the Python side* left. (So, we have more work
>> for new frontend contributors, and less for Pythonists.)
>>
>> I'd love to refer these folks to other parts of the Python packaging and
>> distribution ecosystem so we can improve the whole toolchain. Right now
>> there are 29 open issues in PyPA projects on GitHub marked "good first
>> issue", 11 in Warehouse and most of the rest in pip:
>>
>>
>> https://github.com/issues?utf8=%E2%9C%93&q=user%3Apypa+is%3Aopen+label%3A%22good+first+issue%22+
>>
>> I'm totally fine with giving new volunteers teensy tiny doc fix tasks,
>> "manually test this functionality" tasks, and "check whether this bug is
>> still reproducible" tasks, in case you want to write up some of those.
>> Here's a template we use to make good first issues in Warehouse, in case
>> you want to emulate it:
>> https://github.com/pypa/warehouse/issues/new?template=good-first-issue.md
>>
>>
>> **Good First Issue**: This issue is good for first time contributors. If
>> you've already contributed to Warehouse, please work on [another issue
>> without this
>> label](
>> https://github.com/pypa/warehouse/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22good+first+issue%22
>> )
>> instead. If there is not a corresponding pull request for this issue, it
>> is up for grabs. For directions for getting set up, see our [Getting
>> Started Guide](https://warehouse.pypa.io/development/getting-started/).
>> If you are working on this issue and have questions, please feel free to
>> ask them here, [`#pypa-dev` on
>> Freenode](https://webchat.freenode.net/?channels=%23pypa-dev), or the
>> [pypa-dev mailing list](https://groups.google.com/forum/#!forum/pypa-dev).
>>
>>
>> If your project isn't under https://github.com/pypa , but you want to
>> publicize your good first issues, reply to this thread? Thanks.
>>
>> --
>> Sumana Harihareswara
>> Warehouse project manager
>> Changeset Consulting
>> https://changeset.nyc

From ncoghlan at gmail.com  Fri Apr 13 22:23:18 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 14 Apr 2018 12:23:18 +1000
Subject: [Distutils] PEP 571: Any further manylinux2010 concerns or
 questions?
In-Reply-To: <CADiSq7f6OqETp25bf2=1BO0ya-CA9ZTUJ2K6dsHxaOCU=NfuiA@mail.gmail.com>
References: <CADiSq7d00vsno60jTY1XwKDykj1L0UqzFZvDej1BS4V_4GxXvQ@mail.gmail.com>
 <CADiSq7f6OqETp25bf2=1BO0ya-CA9ZTUJ2K6dsHxaOCU=NfuiA@mail.gmail.com>
Message-ID: <CADiSq7czJLamQz6+1RoGSg2mE=i9uNeR+m+79pzZyWrt35GYiw@mail.gmail.com>

On 12 April 2018 at 21:54, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 30 March 2018 at 20:46, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> PEP link: https://www.python.org/dev/peps/pep-0571/
>>
>> Thomas Kluyver has amended Mark Williams's PEP 571 to address the
>> concerns & questions raised in the previous thread:
>>
>> * manylinux2 -> manylinux2010:
>> https://github.com/python/peps/commit/70cbfda06534aedd6372f489090fdc8e1062de6e#diff-ed6b6d5f928c15489fc02dca72f4b519
>> * using glibc 2.12 as a compatibility marker:
>> https://github.com/python/peps/commit/d43b984e021eddc11bdbc36863c5c285b473f8a7#diff-ed6b6d5f928c15489fc02dca72f4b519
>>
>> (We also dropped a potentially misleading aside that could be taken as
>> implying inaccurate limitations on Anaconda platform compatibility)
>>
>> As I expect quite a few folks will be busy for the Easter weekend, I'm
>> planning to accept the PEP a week from next Monday (i.e on April 9th)
>> if no new concerns or objections are raised between now and then :)
>
> With one small amendment [1] to appropriately credit Geoffrey Thomas
> and to provide a reference link for CalVer, I'm happy to report that
> I'm accepting the manylinux2010 specification :)

With the baseline ABI definition step out of the way, there's now the
non-trivial task of getting this baseline to the point where folks can
actually use it in practice to distribute pre-built binaries for their
projects: https://github.com/pypa/manylinux/issues/179

If you think I've missed any essential steps from that tracking issue,
or if there are other projects you think would be worth mentioning in
the "Other projects to consider..." section, please let me know,
either here, or on the issue.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From p.f.moore at gmail.com  Sat Apr 14 08:47:04 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 14 Apr 2018 13:47:04 +0100
Subject: [Distutils] Pip 10.0 has been released
Message-ID: <CACac1F-poTjztpe6CYJcxxay6ggWSxr=+rdCcPwn2TtEgLh90w@mail.gmail.com>

On behalf of the PyPA, I am pleased to announce that pip 10.0 has just
been released. This release has been the culmination of many months of
work by the community.

To install pip 10.0, you can run

    python -m pip install --upgrade pip

or use get-pip, as described in
https://pip.pypa.io/en/latest/installing. If you are using a version
of pip supplied by your distribution vendor, vendor-supplied upgrades
will be available in due course (or you can use pip 10 in a virtual
environment).

(One minor issue with using get-pip on Windows - when you download
get-pip.py, rename it to something that doesn't include "pip" in the
name, such as "gp.py", as the standard name triggers a check in pip
that aborts the run - this is being tracked in
https://github.com/pypa/pip/issues/5219).

Highlights of the new release:

* Python 2.6 is no longer supported - if you need pip on Python 2.6,
you should stay on pip 9, which is the last version to support Python
2.6.
* Support for PEP 518, which allows projects to specify what packages
they require in order to build from source. (PEP 518 support is
currently limited, with full support coming in future versions - see
the documentation for details).
* Significant improvements in Unicode handling for non-ASCII locales on Windows.
* A new "pip config" command.
* The default upgrade strategy has become "only-if-needed"
* Many bug fixes and minor improvements.

In addition, the previously announced reorganisation of pip's
internals has now taken place. Unless you are the author of code that
imports the pip module (or a user of such code), this change will not
affect you. If you are affected, please report the issue to the author of the
offending code (refer them to
https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html
for the details of the announcement).

Thanks to everyone who put so much effort into the new release. Many
of the contributions came from community members, whether in the form
of code, participation in design discussions, or bug reports. The pip
development team is extremely grateful to everyone in the community
for their contributions.

Thanks,
Paul

From thomas at kluyver.me.uk  Sat Apr 14 08:50:43 2018
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Sat, 14 Apr 2018 13:50:43 +0100
Subject: [Distutils] Pip 10.0 has been released
In-Reply-To: <CACac1F-poTjztpe6CYJcxxay6ggWSxr=+rdCcPwn2TtEgLh90w@mail.gmail.com>
References: <CACac1F-poTjztpe6CYJcxxay6ggWSxr=+rdCcPwn2TtEgLh90w@mail.gmail.com>
Message-ID: <1523710243.1634862.1337850744.3BC916E0@webmail.messagingengine.com>

Thanks and congratulations to everyone who has worked on pip!

On Sat, Apr 14, 2018, at 1:47 PM, Paul Moore wrote:
> On behalf of the PyPA, I am pleased to announce that pip 10.0 has just
> been released. This release has been the culmination of many months of
> work by the community.
> 
> To install pip 10.0, you can run
> 
>     python -m pip install --upgrade pip
> 
> or use get-pip, as described in
> https://pip.pypa.io/en/latest/installing. If you are using a version
> of pip supplied by your distribution vendor, vendor-supplied upgrades
> will be available in due course (or you can use pip 10 in a virtual
> environment).
> 
> (One minor issue with using get-pip on Windows - when you download
> get-pip.py, rename it to something that doesn't include "pip" in the
> name, such as "gp.py", as the standard name triggers a check in pip
> that aborts the run - this is being tracked in
> https://github.com/pypa/pip/issues/5219).
> 
> Highlights of the new release:
> 
> * Python 2.6 is no longer supported - if you need pip on Python 2.6,
> you should stay on pip 9, which is the last version to support Python
> 2.6.
> * Support for PEP 518, which allows projects to specify what packages
> they require in order to build from source. (PEP 518 support is
> currently limited, with full support coming in future versions - see
> the documentation for details).
> * Significant improvements in Unicode handling for non-ASCII locales on Windows.
> * A new "pip config" command.
> * The default upgrade strategy has become "only-if-needed"
> * Many bug fixes and minor improvements.
> 
> In addition, the previously announced reorganisation of pip's
> internals has now taken place. Unless you are the author of code that
> imports the pip module (or a user of such code), this change will not
> affect you. If you are affected, please report the issue to the author of the
> offending code (refer them to
> https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html
> for the details of the announcement).
> 
> Thanks to everyone who put so much effort into the new release. Many
> of the contributions came from community members, whether in the form
> of code, participation in design discussions, or bug reports. The pip
> development team is extremely grateful to everyone in the community
> for their contributions.
> 
> Thanks,
> Paul
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

From wes.turner at gmail.com  Sat Apr 14 09:17:43 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 14 Apr 2018 09:17:43 -0400
Subject: [Distutils] Pip 10.0 has been released
In-Reply-To: <1523710243.1634862.1337850744.3BC916E0@webmail.messagingengine.com>
References: <CACac1F-poTjztpe6CYJcxxay6ggWSxr=+rdCcPwn2TtEgLh90w@mail.gmail.com>
 <1523710243.1634862.1337850744.3BC916E0@webmail.messagingengine.com>
Message-ID: <CACfEFw94TcNQ6t7utGYpoc3=xKW7f5fYBefLxmx43bdOuNHaBQ@mail.gmail.com>

Thanks!

On Saturday, April 14, 2018, Thomas Kluyver <thomas at kluyver.me.uk> wrote:

> Thanks and congratulations to everyone who has worked on pip!
>
> On Sat, Apr 14, 2018, at 1:47 PM, Paul Moore wrote:
> > On behalf of the PyPA, I am pleased to announce that pip 10.0 has just
> > been released. This release has been the culmination of many months of
> > work by the community.
> >
> > To install pip 10.0, you can run
> >
> >     python -m pip install --upgrade pip
> >
> > or use get-pip, as described in
> > https://pip.pypa.io/en/latest/installing. If you are using a version
> > of pip supplied by your distribution vendor, vendor-supplied upgrades
> > will be available in due course (or you can use pip 10 in a virtual
> > environment).
> >
> > (One minor issue with using get-pip on Windows - when you download
> > get-pip.py, rename it to something that doesn't include "pip" in the
> > name, such as "gp.py", as the standard name triggers a check in pip
> > that aborts the run - this is being tracked in
> > https://github.com/pypa/pip/issues/5219).
> >
> > Highlights of the new release:
> >
> > * Python 2.6 is no longer supported - if you need pip on Python 2.6,
> > you should stay on pip 9, which is the last version to support Python
> > 2.6.
> > * Support for PEP 518, which allows projects to specify what packages
> > they require in order to build from source. (PEP 518 support is
> > currently limited, with full support coming in future versions - see
> > the documentation for details).
> > * Significant improvements in Unicode handling for non-ASCII locales on
> Windows.
> > * A new "pip config" command.
> > * The default upgrade strategy has become "only-if-needed"
> > * Many bug fixes and minor improvements.
> >
> > In addition, the previously announced reorganisation of pip's
> > internals has now taken place. Unless you are the author of code that
> > imports the pip module (or a user of such code), this change will not
> > affect you. If you are affected, please report the issue to the author
> of the
> > offending code (refer them to
> > https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html
> > for the details of the announcement).
> >
> > Thanks to everyone who put so much effort into the new release. Many
> > of the contributions came from community members, whether in the form
> > of code, participation in design discussions, or bug reports. The pip
> > development team is extremely grateful to everyone in the community
> > for their contributions.
> >
> > Thanks,
> > Paul
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180414/8bd48aff/attachment.html>

From matthew.brett at gmail.com  Sat Apr 14 16:57:06 2018
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 14 Apr 2018 21:57:06 +0100
Subject: [Distutils] Announcement: Pip 10 is coming,
 and will move all internal APIs
In-Reply-To: <CAE-7VJnuXf8zayaJG8JDCr+deJ-+9tDEDFe6=5e6up_RkyGcdw@mail.gmail.com>
References: <CACac1F8phs-jvpsCKWUnxeuUr5rRmze6SCNsnw95JGFW-jSaZA@mail.gmail.com>
 <CAHrZfZDKVvXNR-H0BfC9CrKjzp==UqcemxtU9AB_0bCuZAcMww@mail.gmail.com>
 <CACac1F-Mv+-aWauJNH_fZFhyhn3ReaEnze24SxWoXAX-ww0WGg@mail.gmail.com>
 <CADiSq7df8CvGQB24UTb+uQxHunrsQHU97Nc6kmOSr+wY99Xg4Q@mail.gmail.com>
 <CACac1F_PkcHekc-2qkas5J6w0xUumjuVJCCMcCGXPF4Ft1zmSw@mail.gmail.com>
 <CAE-7VJnuXf8zayaJG8JDCr+deJ-+9tDEDFe6=5e6up_RkyGcdw@mail.gmail.com>
Message-ID: <CAH6Pt5rBb3KOFMs36vBv3=JqBHY7dT+GR0e21KO4=irUmySAdQ@mail.gmail.com>

Hi,

On Sun, Oct 22, 2017 at 8:52 AM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> 2017-10-21 14:34 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:
>> On 21 October 2017 at 12:15, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> (Note: this is entirely speculative, and I have no idea how hard it would
>>> be, so please read it as the question it's intended to be)
>>
>> No problem - I don't know myself how hard some of this would be, either ;-)
>>
>>> Do you know if there any key APIs (like installation) that could be turned
>>> into wrappers around pip CLI calls in order to mitigate some of the impact?
>>
>> The obvious one is pip.main(). That's the one a lot of people use, but
>> it's easily replaceable by a simple subprocess call. That's actually
>> one of the reasons this was so frustrating to us - the bug reports we
>> got were often from people doing things they didn't need to, that they
>> could handle trivially via a supported approach.
>>
>> Otherwise, no. We've had little or no feedback on the tracker from
>> people using more complex internals, so our working assumption has
>> been there's very little that can't be handled via the CLI or existing
>> packages. Feedback so far from this mail hints that maybe we were
>> wrong, but it's still hard to know if it's one or two key projects, or
>> a whole range of people that we've yet to hear from. I'm pretty sure,
>> for example, that pipenv uses internals, either directly or via one of
>> their dependencies, but we've not seen any feedback from them yet.
>
> Another one that immediately comes to mind is pip-tools [1], which I
> think is quite widely used.
>
> But I just checked, and they filed a "check out how to deal with pip
> 10" issue two days ago [2] (I'm guessing in response to this thread).

Now pip 10 is out, of course, I discover that I've lost the
implementation of `get_supported` in pip.pep425tags.  It's my fault
for not remembering I had used it.

Is the suggestion to use the `_internal` import, or carry a copy of
the pep425tags code myself, that I have to keep up to date with the
internal pip copy?  That would also involve me copying the `glibc`
part of the code.  I see that the `wheel` package has an old copy of
that code too, which doesn't deal with manylinux wheels.    You
probably saw that `pip-tools` ended up vendoring the whole of pip9
[1].

Cheers,

Matthew

[1] https://github.com/jazzband/pip-tools/tree/master/piptools/_vendored/pip

From donald at stufft.io  Sat Apr 14 17:31:41 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 14 Apr 2018 17:31:41 -0400
Subject: [Distutils] Announcement: Pip 10 is coming,
 and will move all internal APIs
In-Reply-To: <CAH6Pt5rBb3KOFMs36vBv3=JqBHY7dT+GR0e21KO4=irUmySAdQ@mail.gmail.com>
References: <CACac1F8phs-jvpsCKWUnxeuUr5rRmze6SCNsnw95JGFW-jSaZA@mail.gmail.com>
 <CAHrZfZDKVvXNR-H0BfC9CrKjzp==UqcemxtU9AB_0bCuZAcMww@mail.gmail.com>
 <CACac1F-Mv+-aWauJNH_fZFhyhn3ReaEnze24SxWoXAX-ww0WGg@mail.gmail.com>
 <CADiSq7df8CvGQB24UTb+uQxHunrsQHU97Nc6kmOSr+wY99Xg4Q@mail.gmail.com>
 <CACac1F_PkcHekc-2qkas5J6w0xUumjuVJCCMcCGXPF4Ft1zmSw@mail.gmail.com>
 <CAE-7VJnuXf8zayaJG8JDCr+deJ-+9tDEDFe6=5e6up_RkyGcdw@mail.gmail.com>
 <CAH6Pt5rBb3KOFMs36vBv3=JqBHY7dT+GR0e21KO4=irUmySAdQ@mail.gmail.com>
Message-ID: <889E9967-06C1-4A88-BA5B-4E28921E4FB9@stufft.io>


> On Apr 14, 2018, at 4:57 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> 
> Is the suggestion to use the `_internal` import, or carry a copy of
> the pep425tags code myself, that I have to keep up to date with the
> internal pip copy?  That would also involve me copying the `glibc`
> part of the code.  I see that the `wheel` package has an old copy of
> that code too, which doesn't deal with manylinux wheels.    You
> probably saw that `pip-tools` ended up vendoring the whole of pip9
> [1].

The best solution is to figure out what APIs people need, and either add them to packaging and have pip consume that as well as anyone else, or make a new library for the same.

If that?s unacceptable, vendoring or version pinning is probably the best option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180414/1a60a9e3/attachment.html>

From ncoghlan at gmail.com  Sat Apr 14 23:17:02 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 15 Apr 2018 13:17:02 +1000
Subject: [Distutils] Pip 10.0 has been released
In-Reply-To: <CACac1F-poTjztpe6CYJcxxay6ggWSxr=+rdCcPwn2TtEgLh90w@mail.gmail.com>
References: <CACac1F-poTjztpe6CYJcxxay6ggWSxr=+rdCcPwn2TtEgLh90w@mail.gmail.com>
Message-ID: <CADiSq7ehYHNWFq0qBeTPzf=6C0+2uOFtjpoN3_pGNhaehFtOmg@mail.gmail.com>

On 14 April 2018 at 22:47, Paul Moore <p.f.moore at gmail.com> wrote:
> On behalf of the PyPA, I am pleased to announce that pip 10.0 has just
> been released. This release has been the culmination of many months of
> work by the community.

Very cool!

Thanks to everyone that helped bring this new release together and get
it into the hands of end users :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Sat Apr 14 23:24:16 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 15 Apr 2018 13:24:16 +1000
Subject: [Distutils] Announcement: Pip 10 is coming,
 and will move all internal APIs
In-Reply-To: <889E9967-06C1-4A88-BA5B-4E28921E4FB9@stufft.io>
References: <CACac1F8phs-jvpsCKWUnxeuUr5rRmze6SCNsnw95JGFW-jSaZA@mail.gmail.com>
 <CAHrZfZDKVvXNR-H0BfC9CrKjzp==UqcemxtU9AB_0bCuZAcMww@mail.gmail.com>
 <CACac1F-Mv+-aWauJNH_fZFhyhn3ReaEnze24SxWoXAX-ww0WGg@mail.gmail.com>
 <CADiSq7df8CvGQB24UTb+uQxHunrsQHU97Nc6kmOSr+wY99Xg4Q@mail.gmail.com>
 <CACac1F_PkcHekc-2qkas5J6w0xUumjuVJCCMcCGXPF4Ft1zmSw@mail.gmail.com>
 <CAE-7VJnuXf8zayaJG8JDCr+deJ-+9tDEDFe6=5e6up_RkyGcdw@mail.gmail.com>
 <CAH6Pt5rBb3KOFMs36vBv3=JqBHY7dT+GR0e21KO4=irUmySAdQ@mail.gmail.com>
 <889E9967-06C1-4A88-BA5B-4E28921E4FB9@stufft.io>
Message-ID: <CADiSq7c7+aRTRdEztSORWUsBk-DAN4bULkLGeWhiwvj+d-aOEw@mail.gmail.com>

On 15 April 2018 at 07:31, Donald Stufft <donald at stufft.io> wrote:
>
> On Apr 14, 2018, at 4:57 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>
> Is the suggestion to use the `_internal` import, or carry a copy of
> the pep425tags code myself, that I have to keep up to date with the
> internal pip copy?  That would also involve me copying the `glibc`
> part of the code.  I see that the `wheel` package has an old copy of
> that code too, which doesn't deal with manylinux wheels.    You
> probably saw that `pip-tools` ended up vendoring the whole of pip9
> [1].
>
> The best solution is to figure out what APIs people need, and either add
> them to packaging and have pip consume that as well as anyone else, or make
> a new library for the same.
>
> If that?s unacceptable, vendoring or version pinning is probably the best
> option.

I think there are going to be at least two steps involved for most
projects affected by the API change:

1. The quick fix to add pip 10 compatibility (which is likely a matter
of "copy the code you need into the project that needs it")
2. The technical debt reduction to reduce code duplication (which is
likely a matter of "add the required APIs to the 'packaging' project")

Step 2 is the step that the pip internals refactoring is designed to
encourage, as we believe a lot of tool developers were just using
pip's internal APIs rather than filing RFEs and submitting PRs to help
guide the evolution of the stable APIs in packaging in a use-case
driven manner.

FWIW, `pipenv`'s currently still on "Step 1" at the moment (and has a
lot of internal refactoring of its own ahead of it before it will
really move on to step 2).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From thomas at kluyver.me.uk  Sun Apr 15 03:31:44 2018
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Sun, 15 Apr 2018 08:31:44 +0100
Subject: [Distutils] Package metadata: which fields are optional
Message-ID: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>

The core metadata specification (https://packaging.python.org/specifications/core-metadata/ ) notes whether each field is optional. However there are some discrepancies with my understanding:

- Download-URL is not marked as optional, but in practice it's obsolete (since PEP 470) and not very helpful (there may be different places to download the same package). Flit has never set this, and I have had no bug reports about it, so in practice it definitely is optional.
- Requires-Python is not marked as optional, though I'm pretty sure it also is in practice.
- Only one of the multiple use fields is explicitly marked as optional, but my understanding is that 'multiple use' includes using them zero times, so they are all optional.

I propose that we remove 'optional' from all the headings, and note at the top of the specification that the required fields are:
- Metadata-Version
- Name
- Version
- Summary

(And we should check if Summary is really required)

Thomas

From donald at stufft.io  Sun Apr 15 03:56:26 2018
From: donald at stufft.io (Donald Stufft)
Date: Sun, 15 Apr 2018 03:56:26 -0400
Subject: [Distutils] Package metadata: which fields are optional
In-Reply-To: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>
References: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>
Message-ID: <36117C18-C05E-46E8-8797-DF523B9D689C@stufft.io>


> On Apr 15, 2018, at 3:31 AM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> 
> The core metadata specification (https://packaging.python.org/specifications/core-metadata/ ) notes whether each field is optional. However there are some discrepancies with my understanding:
> 
> - Download-URL is not marked as optional, but in practice it's obsolete (since PEP 470) and not very helpful (there may be different places to download the same package). Flit has never set this, and I have had no bug reports about it, so in practice it definitely is optional.
> - Requires-Python is not marked as optional, though I'm pretty sure it also is in practice.
> - Only one of the multiple use fields is explicitly marked as optional, but my understanding is that 'multiple use' includes using them zero times, so they are all optional.
> 
> I propose that we remove 'optional' from all the headings, and note at the top of the specification that the required fields are:
> - Metadata-Version
> - Name
> - Version
> - Summary
> 

In PyPI, basically only Metadata-Version, Name, and Version are required.

I?m +1 on this, in practice what distutils does is for any ?mandatory? field that wasn?t filled out, it would give it an implicit value of ?UNKNOWN? (this include Name and Version amusingly enough, but Unknown is already taken on PyPI and Unknown isn?t a valid version anymore). So while it was *technically* set, it was set to a garbage value and thus, for all intents and purposes, optional anyways. We just had a funny way of saying that it didn?t exist.


From ncoghlan at gmail.com  Sun Apr 15 03:57:54 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 15 Apr 2018 17:57:54 +1000
Subject: [Distutils] Package metadata: which fields are optional
In-Reply-To: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>
References: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>
Message-ID: <CADiSq7d=mPQN_ZGqu70HyGG7THzD8=j-EX+SQXjbjxhefZV6Lg@mail.gmail.com>

On 15 April 2018 at 17:31, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> The core metadata specification (https://packaging.python.org/specifications/core-metadata/ ) notes whether each field is optional. However there are some discrepancies with my understanding:
>
> - Download-URL is not marked as optional, but in practice it's obsolete (since PEP 470) and not very helpful (there may be different places to download the same package). Flit has never set this, and I have had no bug reports about it, so in practice it definitely is optional.
> - Requires-Python is not marked as optional, though I'm pretty sure it also is in practice.
> - Only one of the multiple use fields is explicitly marked as optional, but my understanding is that 'multiple use' includes using them zero times, so they are all optional.
>
> I propose that we remove 'optional' from all the headings, and note at the top of the specification that the required fields are:
> - Metadata-Version
> - Name
> - Version
> - Summary
>
> (And we should check if Summary is really required)

That all sounds like a good idea to me.

With the heading adjustments, it would be worth adding the relevant
Sphinx labels so that the current anchors still resolve to the right
place. For example, the current Keywords anchor is
https://packaging.python.org/specifications/core-metadata/#keywords-optional.
With this change, it will become
https://packaging.python.org/specifications/core-metadata/#keywords.
Adding a ".. _keywords-optional:" label before the heading will
preserve the old links.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From thomas at kluyver.me.uk  Sun Apr 15 12:44:59 2018
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Sun, 15 Apr 2018 17:44:59 +0100
Subject: [Distutils] Package metadata: which fields are optional
In-Reply-To: <CADiSq7d=mPQN_ZGqu70HyGG7THzD8=j-EX+SQXjbjxhefZV6Lg@mail.gmail.com>
References: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>
 <CADiSq7d=mPQN_ZGqu70HyGG7THzD8=j-EX+SQXjbjxhefZV6Lg@mail.gmail.com>
Message-ID: <1523810699.3077695.1338670296.0A9EB9A6@webmail.messagingengine.com>

Thanks. I've opened a PR for it:

https://github.com/pypa/python-packaging-user-guide/pull/469

For now, I haven't listed 'Summary' as a required field, but I'm not 100% sure of this. Donald says PyPI doesn't check that it's there, but if all (or almost all) distributions have it anyway, maybe we should enforce that it's always there.

Thomas

On Sun, Apr 15, 2018, at 8:57 AM, Nick Coghlan wrote:
> On 15 April 2018 at 17:31, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> > The core metadata specification (https://packaging.python.org/specifications/core-metadata/ ) notes whether each field is optional. However there are some discrepancies with my understanding:
> >
> > - Download-URL is not marked as optional, but in practice it's obsolete (since PEP 470) and not very helpful (there may be different places to download the same package). Flit has never set this, and I have had no bug reports about it, so in practice it definitely is optional.
> > - Requires-Python is not marked as optional, though I'm pretty sure it also is in practice.
> > - Only one of the multiple use fields is explicitly marked as optional, but my understanding is that 'multiple use' includes using them zero times, so they are all optional.
> >
> > I propose that we remove 'optional' from all the headings, and note at the top of the specification that the required fields are:
> > - Metadata-Version
> > - Name
> > - Version
> > - Summary
> >
> > (And we should check if Summary is really required)
> 
> That all sounds like a good idea to me.
> 
> With the heading adjustments, it would be worth adding the relevant
> Sphinx labels so that the current anchors still resolve to the right
> place. For example, the current Keywords anchor is
> https://packaging.python.org/specifications/core-metadata/#keywords-optional.
> With this change, it will become
> https://packaging.python.org/specifications/core-metadata/#keywords.
> Adding a ".. _keywords-optional:" label before the heading will
> preserve the old links.
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Mon Apr 16 05:39:27 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 16 Apr 2018 19:39:27 +1000
Subject: [Distutils] Package metadata: which fields are optional
In-Reply-To: <1523810699.3077695.1338670296.0A9EB9A6@webmail.messagingengine.com>
References: <1523777504.3040583.1338384832.059B041C@webmail.messagingengine.com>
 <CADiSq7d=mPQN_ZGqu70HyGG7THzD8=j-EX+SQXjbjxhefZV6Lg@mail.gmail.com>
 <1523810699.3077695.1338670296.0A9EB9A6@webmail.messagingengine.com>
Message-ID: <CADiSq7e46CGPNxUXccZbJcM5Z7BrYZxZQb1oTdu5fJ-0WFuc1g@mail.gmail.com>

On 16 April 2018 at 02:44, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> Thanks. I've opened a PR for it:
>
> https://github.com/pypa/python-packaging-user-guide/pull/469
>
> For now, I haven't listed 'Summary' as a required field, but I'm not 100% sure of this. Donald says PyPI doesn't check that it's there, but if all (or almost all) distributions have it anyway, maybe we should enforce that it's always there.

It's easy enough for consuming tools to default Summary to being the
same as Name, so I'm OK with making it officially optional.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From dan at danryan.co  Sun Apr 15 02:21:12 2018
From: dan at danryan.co (Dan Ryan)
Date: Sun, 15 Apr 2018 02:21:12 -0400
Subject: [Distutils] Announcement: Pip 10 is coming,
 and will move all internal APIs
In-Reply-To: <CADiSq7c7+aRTRdEztSORWUsBk-DAN4bULkLGeWhiwvj+d-aOEw@mail.gmail.com>
References: <CACac1F8phs-jvpsCKWUnxeuUr5rRmze6SCNsnw95JGFW-jSaZA@mail.gmail.com>
 <CAHrZfZDKVvXNR-H0BfC9CrKjzp==UqcemxtU9AB_0bCuZAcMww@mail.gmail.com>
 <CACac1F-Mv+-aWauJNH_fZFhyhn3ReaEnze24SxWoXAX-ww0WGg@mail.gmail.com>
 <CADiSq7df8CvGQB24UTb+uQxHunrsQHU97Nc6kmOSr+wY99Xg4Q@mail.gmail.com>
 <CACac1F_PkcHekc-2qkas5J6w0xUumjuVJCCMcCGXPF4Ft1zmSw@mail.gmail.com>
 <CAE-7VJnuXf8zayaJG8JDCr+deJ-+9tDEDFe6=5e6up_RkyGcdw@mail.gmail.com>
 <CAH6Pt5rBb3KOFMs36vBv3=JqBHY7dT+GR0e21KO4=irUmySAdQ@mail.gmail.com>
 <889E9967-06C1-4A88-BA5B-4E28921E4FB9@stufft.io>
 <CADiSq7c7+aRTRdEztSORWUsBk-DAN4bULkLGeWhiwvj+d-aOEw@mail.gmail.com>
Message-ID: <9D3AF2D2-BA13-429F-9B2D-3F64C8DA9456@danryan.co>

FWIW we are using quite a bit of the internal api. My plan was to go over this once we cut over to the new warehouse uris. Of note might be the fact that pip-tools is a core dependency we bundle in pipenv and the current maintainer is a pipenv maintainer as well. For our specific case we have made sizeable changes to the dependency resolution stack and bundling allows us to patch freely. 

I don?t know that we are a good example though, we are doing significantly more with pip internals than the average project

-dan

Dan Ryan // pipenv maintainer
gh: @techalchemy

> On Apr 14, 2018, at 11:24 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>> On 15 April 2018 at 07:31, Donald Stufft <donald at stufft.io> wrote:
>> 
>> On Apr 14, 2018, at 4:57 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> 
>> Is the suggestion to use the `_internal` import, or carry a copy of
>> the pep425tags code myself, that I have to keep up to date with the
>> internal pip copy?  That would also involve me copying the `glibc`
>> part of the code.  I see that the `wheel` package has an old copy of
>> that code too, which doesn't deal with manylinux wheels.    You
>> probably saw that `pip-tools` ended up vendoring the whole of pip9
>> [1].
>> 
>> The best solution is to figure out what APIs people need, and either add
>> them to packaging and have pip consume that as well as anyone else, or make
>> a new library for the same.
>> 
>> If that?s unacceptable, vendoring or version pinning is probably the best
>> option.
> 
> I think there are going to be at least two steps involved for most
> projects affected by the API change:
> 
> 1. The quick fix to add pip 10 compatibility (which is likely a matter
> of "copy the code you need into the project that needs it")
> 2. The technical debt reduction to reduce code duplication (which is
> likely a matter of "add the required APIs to the 'packaging' project")
> 
> Step 2 is the step that the pip internals refactoring is designed to
> encourage, as we believe a lot of tool developers were just using
> pip's internal APIs rather than filing RFEs and submitting PRs to help
> guide the evolution of the stable APIs in packaging in a use-case
> driven manner.
> 
> FWIW, `pipenv`'s currently still on "Step 1" at the moment (and has a
> lot of internal refactoring of its own ahead of it before it will
> really move on to step 2).
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From laura at laura-hampton.com  Mon Apr 16 13:27:53 2018
From: laura at laura-hampton.com (Laura Hampton)
Date: Mon, 16 Apr 2018 13:27:53 -0400
Subject: [Distutils] New PyPI launched, legacy PyPI shutting down April 30
Message-ID: <1523899673.3082967.1339912520.11535256@webmail.messagingengine.com>

New PyPI launched, legacy PyPI shutting down April 30[1]

Starting today, the canonical Python Package Index is at https://pypi.org and uses the new Warehouse codebase.

We announced the https://pypi.org beta on March 26 and your feedback and test usage have helped us get it production-ready.

Monday April 16 (2018-04-16): We launched the new PyPI, redirecting browser traffic and API calls (including "pip install") from pypi.python.org to the new site. The old codebase is still available at https://legacy.pypi.org for now.

Monday April 30 (2018-04-30): We plan to shut down legacy PyPI https://legacy.pypi.org . The address pypi.python.org will continue to redirect to Warehouse.

For more details, see our roadmap: https://wiki.python.org/psf/WarehouseRoadmap

If your site/service links to or uses pypi.python.org, you should start using pypi.org instead: https://warehouse.readthedocs.io/api-reference/integration-guide/#migrating-to-the-new-pypi 

Thank you.

[1] https://blog.python.org/2018/04/new-pypi-launched-legacy-pypi-shutting.html

  Laura Hampton
  laura at laura-hampton dot com

From j.orponen at 4teamwork.ch  Mon Apr 16 14:14:54 2018
From: j.orponen at 4teamwork.ch (Joni Orponen)
Date: Mon, 16 Apr 2018 20:14:54 +0200
Subject: [Distutils] New PyPI launched,
 legacy PyPI shutting down April 30
In-Reply-To: <1523899673.3082967.1339912520.11535256@webmail.messagingengine.com>
References: <1523899673.3082967.1339912520.11535256@webmail.messagingengine.com>
Message-ID: <CA+LW3i1_HQKkS1HNuppEyhjyxxuRg1SMmzb1x2yz5GjAHY2HcQ@mail.gmail.com>

On Mon, Apr 16, 2018 at 7:27 PM, Laura Hampton <laura at laura-hampton.com>
wrote:

> Monday April 30 (2018-04-30): We plan to shut down legacy PyPI
> https://legacy.pypi.org . The address pypi.python.org will continue to
> redirect to Warehouse.
>

Is there a timeline planned for sunsetting this redirect?

-- 
Joni Orponen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180416/8ba9ecf1/attachment.html>

From donald at stufft.io  Mon Apr 16 14:52:04 2018
From: donald at stufft.io (Donald Stufft)
Date: Mon, 16 Apr 2018 14:52:04 -0400
Subject: [Distutils] New PyPI launched,
 legacy PyPI shutting down April 30
In-Reply-To: <CA+LW3i1_HQKkS1HNuppEyhjyxxuRg1SMmzb1x2yz5GjAHY2HcQ@mail.gmail.com>
References: <1523899673.3082967.1339912520.11535256@webmail.messagingengine.com>
 <CA+LW3i1_HQKkS1HNuppEyhjyxxuRg1SMmzb1x2yz5GjAHY2HcQ@mail.gmail.com>
Message-ID: <F8C4AEB2-A967-416C-AAD7-8DA4F8DE4F5C@stufft.io>



> On Apr 16, 2018, at 2:14 PM, Joni Orponen <j.orponen at 4teamwork.ch> wrote:
> 
> On Mon, Apr 16, 2018 at 7:27 PM, Laura Hampton <laura at laura-hampton.com <mailto:laura at laura-hampton.com>> wrote:
> Monday April 30 (2018-04-30): We plan to shut down legacy PyPI https://legacy.pypi.org <https://legacy.pypi.org/> . The address pypi.python.org <http://pypi.python.org/> will continue to redirect to Warehouse.
> 
> Is there a timeline planned for sunsetting this redirect?
> 


The redirect from pypi.python.org <http://pypi.python.org/> to pypi.org <http://pypi.org/>? No defined date, order of magnitude is years, maybe a decade. It?s low cost to keep around (biggest downside is forgetting it exists and accidentally breaking it) and removing it would be highly visible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180416/30d2ea84/attachment.html>

From vinay_sajip at yahoo.co.uk  Mon Apr 16 15:52:39 2018
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Mon, 16 Apr 2018 19:52:39 +0000 (UTC)
Subject: [Distutils] ANN: distlib 0.2.7 released on PyPI
References: <550252852.1474676.1523908359024.ref@mail.yahoo.com>
Message-ID: <550252852.1474676.1523908359024@mail.yahoo.com>

I've just released version 0.2.7 of distlib on PyPI [1]. For newcomers,
distlib is a library of packaging functionality which is intended to be
usable as the basis for third-party packaging tools.

The main changes in this release are as follows:

* Addressed #102: InstalledDistributions now have a modules attribute which is a list
? of top-level modules as read from top_level.txt, if that is in the distribution info.

* Fixed #103: Now https downloads are preferred to those over http. Thanks to
? Saulius ?emaitaitis for the patch.

* Fixed #104: Updated launcher binaries to properly handle interpreter paths with spaces.
? Thanks to Atsushi Odagiri for the diagnosis and fix.

* Fixed #105: cache_from_source is now imported from importlib.util where available.

* Added support for PEP 566 / Metadata 2.1.

A more detailed change log is available at [2].

Please try it out, and if you find any problems or have any suggestions for?improvements,
please give some feedback using the issue tracker! [3]

Regards,

Vinay Sajip

[1]?https://pypi.org/project/distlib/0.2.7/?
[2] https://goo.gl/M3kQzR
[3] https://bitbucket.org/pypa/distlib/issues/new

From lele at metapensiero.it  Mon Apr 16 18:33:02 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Tue, 17 Apr 2018 00:33:02 +0200
Subject: [Distutils] Feed of latest releases on pypi.org
References: <46E9C5AD-A689-443B-9CE5-19922780D5D1@stufft.io>
 <87zid0hs97.fsf@metapensiero.it>
 <F1F0F9DF-DAC3-4D81-B499-E599EEDCA595@stufft.io>
 <41197D43-E504-40F8-8FDA-40E150C23B5B@stufft.io>
Message-ID: <871sfeeq8x.fsf_-_@metapensiero.it>

First of all, congrats to everybody for the successful deploy!

A little less than an year ago we had the following exchange:

Donald Stufft <donald at stufft.io> writes:
>
>> On Jun 22, 2017, at 1:37 PM, Donald Stufft <donald at stufft.io> wrote:
>> 
>>> On Jun 22, 2017, at 1:00 PM, Lele Gaifax <lele at metapensiero.it> wrote:
>>> 
>>> As I'm used to keep an eye from time to time on
>>> https://pypi.python.org/pypi <https://pypi.python.org/pypi>, just to spot
>>> relevant upgrades, or see something new that catches my attention, I
>>> wonder if the new interface offers a similar view, or some kind of RSS
>>> feed, with more than the five "New Releases" box.
>>> 
>>
>> Can you open an issue on https://github.com/pypa/warehouse?
>> <https://github.com/pypa/warehouse?> I think we could probably add
>> something along this lines. At a minimum an RSS feed should be easy (which
>> I think we already have, but it may not be a great one) but I?m thinking
>> maybe the search interface could allow ordering by last update too, then
>> you can search for nothing and get the most recently updated things across
>> the entire site, but it would also let you search for say ?Django? and get
>> the most recently updated things that have to do with Django.
>> 
>
> Oh never mind, this already works: https://pypi.org/search/?q=&o=-created

Today, looking around on the new site, I realized that the above does not work
anymore. Is there any alternative?

Thanks&bye, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.


From ncoghlan at gmail.com  Tue Apr 17 06:42:05 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 17 Apr 2018 20:42:05 +1000
Subject: [Distutils] Feed of latest releases on pypi.org
In-Reply-To: <871sfeeq8x.fsf_-_@metapensiero.it>
References: <46E9C5AD-A689-443B-9CE5-19922780D5D1@stufft.io>
 <87zid0hs97.fsf@metapensiero.it>
 <F1F0F9DF-DAC3-4D81-B499-E599EEDCA595@stufft.io>
 <41197D43-E504-40F8-8FDA-40E150C23B5B@stufft.io>
 <871sfeeq8x.fsf_-_@metapensiero.it>
Message-ID: <CADiSq7c7D2+Podz0ZgPU=dwbQFj_DdW5Xer909wXFMua2DzHqA@mail.gmail.com>

On 17 April 2018 at 08:33, Lele Gaifax <lele at metapensiero.it> wrote:
>> Oh never mind, this already works: https://pypi.org/search/?q=&o=-created
>
> Today, looking around on the new site, I realized that the above does not work
> anymore. Is there any alternative?

I'm not sure of the status of any search syntax changes, but the
Warehouse RSS feeds are covered at
https://warehouse.readthedocs.io/api-reference/feeds/ (those feeds did
exist on Legacy PyPI, but the Warehouse implementation tidies up some
inconsistencies in the data they provide)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From trishank.kuppusamy at datadoghq.com  Wed Apr 18 13:22:06 2018
From: trishank.kuppusamy at datadoghq.com (Trishank Kuppusamy)
Date: Wed, 18 Apr 2018 17:22:06 +0000
Subject: [Distutils] Summary of PyPI overhaul in new LWN article
In-Reply-To: <CAEd-exMcpR_3GzMKLrw4dAGecuB5Q7tjio7e-bBQc73VJoop-A@mail.gmail.com>
References: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>
 <CAEd-exP_2jJLYc5na_q-A1bQr+Kfh-ZYsa00OKsa+8cUq=iHag@mail.gmail.com>
 <CACfEFw_NCa-4oJdGRr1Vyoqn8vytWmoYByWLnTqLS9YXjr5urA@mail.gmail.com>
 <CAEd-exMcpR_3GzMKLrw4dAGecuB5Q7tjio7e-bBQc73VJoop-A@mail.gmail.com>
Message-ID: <CAEd-exNz32Scaq=QDW=pJsxwuge-THZbOBg4W+6a78jX9twBrw@mail.gmail.com>

On Thu, Apr 12, 2018 at 5:29 PM, Trishank Kuppusamy <
trishank.kuppusamy at datadoghq.com> wrote:

> Hi Wes,
>
> On Thu, Apr 12, 2018 at 1:22 PM, Wes Turner <wes.turner at gmail.com> wrote:
>
>> > Are there pypa/warehouse github issues for implementing the TUF trust
>> root support in warehouse; and client support in pip (or a module that pip
>> and other tools can use)?
>>
>
> For client support in pip, we are discussing this patch with Donald Stufft:
>
> https://github.com/pypa/pip/compare/release/9.0.3...trishank
> atdatadog:trishankatdatadog/9.0.3.tuf-in-toto
>
> Happy to discuss more with anyone interested!
>

Sorry for the noise, but our repo has now moved here:

https://github.com/pypa/pip/compare/9.0.3...DataDog:
trishankatdatadog/9.0.3.tuf-in-toto

-- 
https://keybase.io/trishankdatadog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180418/0c381e3e/attachment.html>

From sh at changeset.nyc  Wed Apr 18 16:31:50 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Wed, 18 Apr 2018 16:31:50 -0400
Subject: [Distutils] Warehouse/PyPI update: launch,
 project wrapup approaching
Message-ID: <1524083510.1145793.1342702048.50539AE8@webmail.messagingengine.com>

On Monday, we launched Warehouse and redirected[1] browser and API
traffic so Warehouse is now the codebase, and http://pypi.org/ is the
site, serving nearly everyone who requests files from PyPI. The old
codebase is now up at http://legacy.pypi.org/ temporarily. We had a few
hiccups (incident report)[2] and are now fixing up some search,
indexing, caching, encoding, API compatibility, and UI issues. We're
monitoring incoming bug reports and, so far, don't see anything new that
absolutely needs fixing before we shut down the legacy site on Monday,
April 30th.
https://github.com/pypa/warehouse/projects/1 is the rollout board you can watch to see our progress, and our weekly meeting notes are up[3]. Please continue to report bugs -- if you know they're in PyPI, file them against Warehouse[4], and if you're not sure, file them in the "packaging problems" repository[5].
(The "nearly everyone" in that first sentence above is because of this
User-Agent exclusion[6], and because I'm sure a few users are specifying
legacy.pypi.org in their requests right now while working on forwards
compatibility.)
We've made a number of user-visible improvements in the past couple
weeks. For instance, we added a "switch to desktop version" link in the
mobile view[7], fixed dropdowns for accessibility[8], added user help[9]
for folks affected by the TLS 1.0/1.1 deprecation (mea culpa[10], we
should have done that sooner), and created a page thanking our
sponsors[11].
And we've made many backend improvements to performance, API
compatibility with legacy, sorting and indexing, instrumentation for
metrics, and security -- and Donald implemented[12] email sending via
SES. Thanks[13] to Noah Kantrowitz for reporting a privacy concern
regarding Gravatar URLs and leaking users' email addresses (fixed[14]).
It is not feasible for me to summarize all the work that volunteers put
in, as testers, coders, code reviewers, writers, and user support
helpers within the last two weeks. We have an embarrassment of riches
here. Since April 3rd (two weeks ago) we've merged 98 PRs to
Warehouse[15]; thanks to ymyzk, reaperhulk, glasnt, alex, RazerM,
bskinn, saxenanurag, hugovk, waseem18, cheungnj, contrepoint,
yeraydiazdiaz, jonparrott, jMuzsik, and aalmazan for those. And I'd also
like to thank the many people who, on their own, provided and continue
to provide help to affected users on IRC, Twitter, StackOverflow, and
elsewhere.
We don't have any virtual office hours coming up, but we have some other
events planned. The Talk Python to Me podcast[16] just interviewed
Dustin, Nicole, and Ernest for an  upcoming episode. Dustin will be
speaking on PyPI and packaging in general at PyCon NA in May[17] and at
SciPy in July[18], and we're sprinting at PyCon and EuroPython[19] --
join us? And if you're in New York City, you can join Laura and me for a
Warehouse sprint night[20] on Thursday, April 26th.
And the project's starting to wrap up. Our MOSS funding (thanks to
Mozilla[21] for their support[22] for the PyPI & Warehousework!) is nearly finished; after we shut down the legacy site on April
30th, the general pace of Warehouse development may slow down.
(Warehouse has far more volunteer contributors than it did when we
started MOSS-funded work in early December, but maintainer time
available will diminish.) So we're seeking further funding, to speed up
security and accessibility work, (potentially) localization,
group/organization support[23], better notifications, better
staging/testing workflow for project maintainers, GitHub signon, and
more (see the "Post-Legacy shutdown" milestone[24] and "cool but not
urgent" milestone[25]). We have submitted a few more grant proposals and
are waiting to hear back. And donations to the Python Software
Foundation?s Packaging Working Group, which works to sustain PyPI, pip,
setuptools, and all other Python Packaging Ecosystem efforts, can now be
made on a recurring basis! Please check out https://donate.pypi.org/
and consider pitching in or spreading the word. I'm working on writing
up and sharing a more structured list explaining what we could do at
various levels of funding.
Thanks as always. Please keep the kind words, bug reports, and -- I hope
-- funding coming! :)--
Sumana Harihareswara
Warehouse/PyPI project manager
Changeset Consulting
sh at changeset.nyc



Links:

   1. https://github.com/python/pypi-infra/commits/master
   2. https://status.python.org/incidents/mgjw1g5yjy5j
   3. https://wiki.python.org/psf/PackagingWG/2018-04-17-Warehouse
   4. https://github.com/pypa/warehouse/issues
   5. https://github.com/pypa/packaging-problems/issues/
   6. https://github.com/pypa/warehouse/issues/3275
   7. https://github.com/pypa/warehouse/pull/3602
   8. https://github.com/pypa/warehouse/pull/3287
   9. https://pypi.org/help/#tls-deprecation
  10. https://groups.google.com/d/msg/pypa-dev/Oz6SGA7gefo/UXCu7jM6AQAJ
  11. https://pypi.org/sponsors/
  12. https://github.com/pypa/warehouse/pull/3580
  13. https://twitter.com/EWDurbin/status/984562893864816640
  14. https://github.com/pypa/warehouse/pull/3648
  15. https://github.com/pypa/warehouse/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged+updated%3A%3C2018-04-19+merged%3A%3E2018-04-03++-author%3Apyup-bot+
  16. https://talkpython.fm/
  17. https://us.pycon.org/2018/schedule/presentation/148/
  18. https://scipy2018.scipy.org/ehome/index.php?eventid=299527&tabid=712461&cid=2233540&sessionid=21620161&sessionchoice=1&
  19. https://wiki.python.org/psf/PackagingSprints
  20. https://www.meetup.com/nycpython/events/249722192/
  21. https://blog.mozilla.org/blog/2018/01/23/moss-q4-supporting-python-ecosystem/
  22. https://pyfound.blogspot.com/2017/11/the-psf-awarded-moss-grant-pypi.html
  23. https://github.com/pypa/warehouse/issues/201
  24. https://github.com/pypa/warehouse/milestone/12
  25. https://github.com/pypa/warehouse/milestone/11
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180418/6a9d7965/attachment.html>

From niharika1883 at gmail.com  Wed Apr 18 18:16:18 2018
From: niharika1883 at gmail.com (Niharika Jakhar)
Date: Wed, 18 Apr 2018 22:16:18 +0000
Subject: [Distutils] File handling- tab separated files
Message-ID: <CABrCUu0nzUoSGR1CpM2ftg23HMNXrQ5qdNa=BL1vkHnC=0tFuw@mail.gmail.com>

Hello

I am having trouble opening and reading a Tab separated file(big data). I
stored the data the data in a list and then used the split function (\t) to
tried to print a list of 0 to 100 position. But it is resulting in random
values from the files.

Please let me know, if you deal with such queries, if not, can you please
suggest me some good source in order to solve this problem.

Thanking you in advance

Best regards
NIHARIKA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180418/6d2beb37/attachment-0001.html>

From wes.turner at gmail.com  Wed Apr 18 19:08:47 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Wed, 18 Apr 2018 19:08:47 -0400
Subject: [Distutils] File handling- tab separated files
In-Reply-To: <CABrCUu0nzUoSGR1CpM2ftg23HMNXrQ5qdNa=BL1vkHnC=0tFuw@mail.gmail.com>
References: <CABrCUu0nzUoSGR1CpM2ftg23HMNXrQ5qdNa=BL1vkHnC=0tFuw@mail.gmail.com>
Message-ID: <CACfEFw8UED8_02Bgs0KvvVjhLMKiHCjyy2Fg2ctCmgMjEjReQw@mail.gmail.com>

This is the python distutils list for discussions regarding python
packaging.

For help with using the Python standard library, try the docs and/or the
python tutor mailing list.

https://www.google.com/search?q=site:docs.python.org+tsv

https://www.python.org/community/lists/#tutor
https://markmail.org/search/?q=list:org.python.tutor+tsv

https://www.reddit.com/r/learnpython/
https://www.reddit.com/r/learnpython/search?q=tsv

What you describe should be possible by setting delimiter='\t' with
csv.reader with the CSV module in the Python standard library:

https://docs.python.org/3/library/csv.html#csv.reader
https://docs.python.org/3/library/csv.html#csv.Dialect.delimiter

Various third party packages are faster at reading delimited files or have
additional useful functionality:

http://docs.python-tablib.org/en/master/

https://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html
https://docs.scipy.org/doc/numpy/reference/generated/numpy.genfromtxt.html#numpy.genfromtxt

https://pandas.pydata.org/pandas-docs/stable/io.html#csv-text-files
https://pandas.pydata.org/pandas-docs/stable/generated/pandas.read_csv.html

On Wednesday, April 18, 2018, Niharika Jakhar <niharika1883 at gmail.com>
wrote:

> Hello
>
> I am having trouble opening and reading a Tab separated file(big data). I
> stored the data the data in a list and then used the split function (\t) to
> tried to print a list of 0 to 100 position. But it is resulting in random
> values from the files.
>
> Please let me know, if you deal with such queries, if not, can you please
> suggest me some good source in order to solve this problem.
>
> Thanking you in advance
>
> Best regards
> NIHARIKA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180418/61052ebe/attachment.html>

From niharika1883 at gmail.com  Wed Apr 18 19:09:29 2018
From: niharika1883 at gmail.com (Niharika Jakhar)
Date: Wed, 18 Apr 2018 23:09:29 +0000
Subject: [Distutils] File handling- tab separated files
In-Reply-To: <CACfEFw8UED8_02Bgs0KvvVjhLMKiHCjyy2Fg2ctCmgMjEjReQw@mail.gmail.com>
References: <CABrCUu0nzUoSGR1CpM2ftg23HMNXrQ5qdNa=BL1vkHnC=0tFuw@mail.gmail.com>
 <CACfEFw8UED8_02Bgs0KvvVjhLMKiHCjyy2Fg2ctCmgMjEjReQw@mail.gmail.com>
Message-ID: <CABrCUu2-qFnNHfZBcomjYbvc+JB=0k3=48of29odCqyLSF-YQw@mail.gmail.com>

Thanks, I'll check them out.

On Thu 19 Apr, 2018, 01:08 Wes Turner, <wes.turner at gmail.com> wrote:

> This is the python distutils list for discussions regarding python
> packaging.
>
> For help with using the Python standard library, try the docs and/or the
> python tutor mailing list.
>
> https://www.google.com/search?q=site:docs.python.org+tsv
>
> https://www.python.org/community/lists/#tutor
> https://markmail.org/search/?q=list:org.python.tutor+tsv
>
> https://www.reddit.com/r/learnpython/
> https://www.reddit.com/r/learnpython/search?q=tsv
>
> What you describe should be possible by setting delimiter='\t' with
> csv.reader with the CSV module in the Python standard library:
>
> https://docs.python.org/3/library/csv.html#csv.reader
> https://docs.python.org/3/library/csv.html#csv.Dialect.delimiter
>
> Various third party packages are faster at reading delimited files or have
> additional useful functionality:
>
> http://docs.python-tablib.org/en/master/
>
> https://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html
>
> https://docs.scipy.org/doc/numpy/reference/generated/numpy.genfromtxt.html#numpy.genfromtxt
>
> https://pandas.pydata.org/pandas-docs/stable/io.html#csv-text-files
> https://pandas.pydata.org/pandas-docs/stable/generated/pandas.read_csv.html
>
> On Wednesday, April 18, 2018, Niharika Jakhar <niharika1883 at gmail.com>
> wrote:
>
>> Hello
>>
>> I am having trouble opening and reading a Tab separated file(big data). I
>> stored the data the data in a list and then used the split function (\t) to
>> tried to print a list of 0 to 100 position. But it is resulting in random
>> values from the files.
>>
>> Please let me know, if you deal with such queries, if not, can you please
>> suggest me some good source in order to solve this problem.
>>
>> Thanking you in advance
>>
>> Best regards
>> NIHARIKA
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180418/d88cf0e9/attachment.html>

From p.f.moore at gmail.com  Thu Apr 19 15:18:16 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 19 Apr 2018 20:18:16 +0100
Subject: [Distutils] Pip 10.0.1 has been released
Message-ID: <CACac1F92t3fQCqW+d1_aa9=rxPa_X97ptm4HbcNb+X29qkg6HA@mail.gmail.com>

On behalf of the PyPA, I am pleased to announce that pip 10.0.1 has
just been released.

This release fixes a number of issues with the initial release of pip
10.0, notably:

* A problem with running the "pip.exe" wrapper script on Windows from
a directory with a space in the name.
* A problem with get-pip.py needing to be renamed on Windows to avoid
triggering a check in pip that aborts the run.
* A problem with build isolation when pip is installed as --user
* An issue with the vendored msgpack library on older versions of Python 2.7
* A problem with pip installing from non-editable VCS URLs

Thanks to all the people who reported issues and helped with the fixes.

Paul

From donald at stufft.io  Fri Apr 20 22:07:46 2018
From: donald at stufft.io (Donald Stufft)
Date: Fri, 20 Apr 2018 22:07:46 -0400
Subject: [Distutils] Improving Communication
Message-ID: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>

Currently in the packaging space, we have a number of avenues for communication, which are:

- distutils-sig
- pypa-dev
- virtualenv-users
- Other project specific mailing lists
- IRC
- gitter
- Various issue trackers spread across multiple platforms.
- Probably more places I?m not remembering.

The result of this is that all discussion ends up being super fractured amongst the various places. Sometimes that is exactly what you want (for instance, someone who is working on the wheel specs probably doesn?t care about deprecation policy and internal module renaming in pip) and sometimes that ends up being the opposite of what you want (for instance, when you?re describing something that touches PyPI, setuptools, flit, pip, etc all at once).

Theoretically the idea is that distutils-sig is where cross project reaching stuff goes, IRC/gitter is where real time discussion goes, and the various project mailing lists and issue trackers are where the project specific bits go. The problem is that often times doesn?t actually happen in practice except for the largest and most obvious of changes.

I think our current ?communications stack? kind of sucks, and I?d love to figure out a better way for us to handle this that solves the sort of weird ?independent but related? set of projects we have here.

From my POV, a list of our major problems are:

* Discussion gets fractured across a variety of platforms and locations, which can make it difficult to actually keep up with what?s going on but also to know how to loop in someone relevant if their input would be valuable. You have to more or less simultaneously know someone?s email, Github username, IRC nick, bitbucket username, etc to be able to bring threads of discussion to people?s attention.

* It?s not always clear to users where a discussion should go, often times they?ll come to one location and need to get redirected to another location. If any discussion did happen in the incorrect location, it tends to need to get restarted in the new location (and depending on the specific platform, it may be impossible to actually redirect everyone over to the proper location, so you again, end up fractured with the discussion happening in two places).

* A lot of the technology in this stack is particularly old, and lacks a lot of the modern day affordances that newer things have. An example is being able to edit a discussion post to fix typos that can hinder the ability of others to actually understand whats being talked about. In your typical mailing list or IRC there?s no mechanism by which you can edit an already sent message, so your only option is to either let the problem ride and hope it doesn?t trip up too many people, or send an additional message to correct the error. However these show up as additional, later messages which someone might not even see until they?ve already been thoroughly confused by the first message (since people tend to read email/IRC in a linear fashion).
  - There is a lot of things in this one, other things are things like being able to control in a more fine grained manner what email you?re going to get.
  - Holy crap, formatting and typography to make things actually readable and not a big block of plaintext.

* We don?t have a clear way for users to get help, leaving users to treat random issues, discussion areas, etc as a support forum, rather than some place that?s actually optimized for that. Some of this ties back into some of the earlier things too, where it?s hard to actually redirect discussions 

These aren?t *new* problems, and often times the existing members of a community are the least effected becasue they?ve already spent effort learning the ins and outs and also curating a (typically custom) workflow that they?ve grown accustomed too. The problem with that is that often times that means that new users are left out, and the community gets smaller and smaller as time goes on as people leave and aren?t replaced with new blood, because they?re driven off but the issues with the stack.

A big part of the place this is coming from, is me sitting back and realizing that I tend to be drawn towards pulling discussions into Github issues rather than onto the varying mailing lists, not because that?s always the most appropriate place for it, but because it?s the least painful place in terms of features and functionality. I figure if I?m doing that, when I already have a significant investment in setting up tooling and being involved here, that others (and particularly new users) are likely feeling the same way.

- Donald


From wes.turner at gmail.com  Fri Apr 20 22:53:55 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Fri, 20 Apr 2018 22:53:55 -0400
Subject: [Distutils] Improving Communication
In-Reply-To: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
Message-ID: <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>

On Friday, April 20, 2018, Donald Stufft <donald at stufft.io> wrote:

> Currently in the packaging space, we have a number of avenues for
> communication, which are:
>
> - distutils-sig
> - pypa-dev
> - virtualenv-users
> - Other project specific mailing lists
> - IRC
> - gitter
> - Various issue trackers spread across multiple platforms.
> - Probably more places I?m not remembering.


Is there something like a collaboration plan with a decision tree / flow
chart / list of what types of communications are best communicated on which
platform?

GitHub Team Discussions [1]
- threaded
- editable
- trackbackable (I think?)
- @user notifications
- email replies
- cross-repo
- public / team-only
- Unfortunately, they're not real time like IRC/Gitter

[1] https://blog.github.com/2017-11-20-introducing-team-discussions/


>
> The result of this is that all discussion ends up being super fractured
> amongst the various places. Sometimes that is exactly what you want (for
> instance, someone who is working on the wheel specs probably doesn?t care
> about deprecation policy and internal module renaming in pip) and sometimes
> that ends up being the opposite of what you want (for instance, when you?re
> describing something that touches PyPI, setuptools, flit, pip, etc all at
> once).
>
> Theoretically the idea is that distutils-sig is where cross project
> reaching stuff goes, IRC/gitter is where real time discussion goes, and the
> various project mailing lists and issue trackers are where the project
> specific bits go. The problem is that often times doesn?t actually happen
> in practice except for the largest and most obvious of changes.


"Please refer to the communications flowchart: [url]"


>
> I think our current ?communications stack? kind of sucks, and I?d love to
> figure out a better way for us to handle this that solves the sort of weird
> ?independent but related? set of projects we have here.


Do GitHub project boards help?

Team email and web notifications on GitHub work like this:
@pypa/core



>
> From my POV, a list of our major problems are:
>
> * Discussion gets fractured across a variety of platforms and locations,
> which can make it difficult to actually keep up with what?s going on but
> also to know how to loop in someone relevant if their input would be
> valuable. You have to more or less simultaneously know someone?s email,
> Github username, IRC nick, bitbucket username, etc to be able to bring
> threads of discussion to people?s attention.


A collaboration plan might include this contact information for each team
member


>
> * It?s not always clear to users where a discussion should go, often times
> they?ll come to one location and need to get redirected to another
> location. If any discussion did happen in the incorrect location, it tends
> to need to get restarted in the new location (and depending on the specific
> platform, it may be impossible to actually redirect everyone over to the
> proper location, so you again, end up fractured with the discussion
> happening in two places).


IDK how many times we've discussed upgrading mailman to add per message
footer links to relayed messages. Google Groups has this feature on by
default.


>
> * A lot of the technology in this stack is particularly old, and lacks a
> lot of the modern day affordances that newer things have. An example is
> being able to edit a discussion post to fix typos that can hinder the
> ability of others to actually understand whats being talked about. In your
> typical mailing list or IRC there?s no mechanism by which you can edit an
> already sent message, so your only option is to either let the problem ride
> and hope it doesn?t trip up too many people, or send an additional message
> to correct the error. However these show up as additional, later messages
> which someone might not even see until they?ve already been thoroughly
> confused by the first message (since people tend to read email/IRC in a
> linear fashion).


Issues, Pull Requests, Wikis, and Team Discussions are all editable.

[EDIT]

I EDITED THIS.


>   - There is a lot of things in this one, other things are things like
> being able to control in a more fine grained manner what email you?re going
> to get.


One can unsubscribe from issue notifications


>   - Holy crap, formatting and typography to make things actually readable
> and not a big block of plaintext.


This is a fenced code block in Markdown and GFM: (GitHub Flavored Markdown)

```python
__import__('this')
```

These create a trackback on the mentioned issue:

  #1
  pypa/pip#1


This sends notifications to each mentioned user according to their GitHub
notification settings:

  /cc @westurner @dstufft @pypa/core


> * We don?t have a clear way for users to get help, leaving users to treat
> random issues, discussion areas, etc as a support forum, rather than some
> place that?s actually optimized for that. Some of this ties back into some
> of the earlier things too, where it?s hard to actually redirect discussions


- Search org/project/issues [2]
- Search stack overflow,
- Create an issue

[2] https://github.com/sindresorhus/refined-github
"Display possibly related issues on the 'New Issue' page"
https://github.com/sindresorhus/refined-github/pull/1188



>
> These aren?t *new* problems, and often times the existing members of a
> community are the least effected becasue they?ve already spent effort
> learning the ins and outs and also curating a (typically custom) workflow
> that they?ve grown accustomed too. The problem with that is that often
> times that means that new users are left out, and the community gets
> smaller and smaller as time goes on as people leave and aren?t replaced
> with new blood, because they?re driven off but the issues with the stack.


Is this in the contributing docs? In CONTRIBUTING.rst [3]

Are there standard ISSUE_TEMPLATE/name.md and PULL_REQUEST_TEMPLATE/name.md
? [3]
https://github.com/joelparkerhenderson/github_special_files_and_paths


>
> A big part of the place this is coming from, is me sitting back and
> realizing that I tend to be drawn towards pulling discussions into Github
> issues rather than onto the varying mailing lists, not because that?s
> always the most appropriate place for it, but because it?s the least
> painful place in terms of features and functionality. I figure if I?m doing
> that, when I already have a significant investment in setting up tooling
> and being involved here, that others (and particularly new users) are
> likely feeling the same way.


A bot that watches the [mailing lists,] and adds issue/PR trackbacks might
be super useful.

Each service has information access optimizations that people like most.
GitHub is designed for software development. These days, I send feature
requests to support at github.com with an "ENH: ..." subject line.


>
> - Donald
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180420/db04f59b/attachment-0001.html>

From ncoghlan at gmail.com  Sat Apr 21 00:54:35 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 21 Apr 2018 14:54:35 +1000
Subject: [Distutils] Improving Communication
In-Reply-To: <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>
Message-ID: <CADiSq7cN58F0CgMTsW1APEBKVy6nZ66mOYrkFvGQvKXxfDYQKw@mail.gmail.com>

On 21 April 2018 at 12:53, Wes Turner <wes.turner at gmail.com> wrote:
[Donald wrote]
>> * It?s not always clear to users where a discussion should go, often times
>> they?ll come to one location and need to get redirected to another location.
>> If any discussion did happen in the incorrect location, it tends to need to
>> get restarted in the new location (and depending on the specific platform,
>> it may be impossible to actually redirect everyone over to the proper
>> location, so you again, end up fractured with the discussion happening in
>> two places).
>
> IDK how many times we've discussed upgrading mailman to add per message
> footer links to relayed messages. Google Groups has this feature on by
> default.

While it's only a small piece of the larger puzzle, I've finally
written to distutils-sig-owner about initiating an upgrade to MM3 for
the list. That's far from solving the fractured communications
problem, but it will at least give distutils-sig itself an integrated
web gateway.

I also filed https://github.com/pypa/packaging-problems/issues/141 to
note that it's currently really unclear who's actually handling the
list admin responsibilities for distutils-sig.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From waynejwerner at gmail.com  Sat Apr 21 05:18:13 2018
From: waynejwerner at gmail.com (Wayne Werner)
Date: Sat, 21 Apr 2018 09:18:13 +0000
Subject: [Distutils] Improving Communication
In-Reply-To: <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>
Message-ID: <CAPM86NcRGSC24AH8N9_nP63bUQoWev6b=UoXJWW2zCP4srESwQ@mail.gmail.com>

On Fri, Apr 20, 2018, 9:54 PM Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Friday, April 20, 2018, Donald Stufft <donald at stufft.io> wrote:
>
>>
>>
>> * A lot of the technology in this stack is particularly old, and lacks a
>> lot of the modern day affordances that newer things have. An example is
>> being able to edit a discussion post to fix typos that can hinder the
>> ability of others to actually understand whats being talked about. In your
>> typical mailing list or IRC there?s no mechanism by which you can edit an
>> already sent message, so your only option is to either let the problem ride
>> and hope it doesn?t trip up too many people, or send an additional message
>> to correct the error. However these show up as additional, later messages
>> which someone might not even see until they?ve already been thoroughly
>> confused by the first message (since people tend to read email/IRC in a
>> linear fashion).
>
>
> Issues, Pull Requests, Wikis, and Team Discussions are all editable.
>

Though one thing I've noticed is that a lot of issues get created and
responded to via email clients that hide the existing message so someone
will say "I agree" or worse, +1, and then there's 400 line of email. I
don't know if GH has fixed the display on those things yet.

FWIW.

-W

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/0366631a/attachment.html>

From dirk.avery at gmail.com  Fri Apr 20 18:49:41 2018
From: dirk.avery at gmail.com (Dirk Avery)
Date: Fri, 20 Apr 2018 18:49:41 -0400
Subject: [Distutils] saveopts without installing?
Message-ID: <0B7ADE3D-0829-4DCB-963F-4BF9A0566392@gmail.com>

For automation project, trying to get all options set by setup.py and setup.cfg without actually installing. Possible?

From trishank.kuppusamy at datadoghq.com  Wed Apr 18 17:42:34 2018
From: trishank.kuppusamy at datadoghq.com (Trishank Kuppusamy)
Date: Wed, 18 Apr 2018 21:42:34 +0000
Subject: [Distutils] Summary of PyPI overhaul in new LWN article
In-Reply-To: <CAEd-exNz32Scaq=QDW=pJsxwuge-THZbOBg4W+6a78jX9twBrw@mail.gmail.com>
References: <42c0c824-9fa3-689b-f240-718d5cc7e8db@changeset.nyc>
 <CAEd-exP_2jJLYc5na_q-A1bQr+Kfh-ZYsa00OKsa+8cUq=iHag@mail.gmail.com>
 <CACfEFw_NCa-4oJdGRr1Vyoqn8vytWmoYByWLnTqLS9YXjr5urA@mail.gmail.com>
 <CAEd-exMcpR_3GzMKLrw4dAGecuB5Q7tjio7e-bBQc73VJoop-A@mail.gmail.com>
 <CAEd-exNz32Scaq=QDW=pJsxwuge-THZbOBg4W+6a78jX9twBrw@mail.gmail.com>
Message-ID: <CAEd-exP=KfMgPd=4Aqo6ctMirNJHYw3RN+BOUys7vfML9ubJtw@mail.gmail.com>

https://github.com/pypa/pip/compare/10.0.0...DataDog:trishankatdatadog/10.0.0.tuf-in-toto

-- 
https://keybase.io/trishankdatadog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180418/1362d960/attachment.html>

From wes.turner at gmail.com  Sat Apr 21 15:59:02 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 21 Apr 2018 15:59:02 -0400
Subject: [Distutils] Improving Communication
In-Reply-To: <CAPM86NcRGSC24AH8N9_nP63bUQoWev6b=UoXJWW2zCP4srESwQ@mail.gmail.com>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>
 <CAPM86NcRGSC24AH8N9_nP63bUQoWev6b=UoXJWW2zCP4srESwQ@mail.gmail.com>
Message-ID: <CACfEFw-NQvo+h7AYTFoiXfu-Z0JpoPF78QdZj1kWEv-=9DXLSA@mail.gmail.com>

On Saturday, April 21, 2018, Wayne Werner <waynejwerner at gmail.com> wrote:

>
>
> On Fri, Apr 20, 2018, 9:54 PM Wes Turner <wes.turner at gmail.com> wrote:
>
>>
>>
>> On Friday, April 20, 2018, Donald Stufft <donald at stufft.io> wrote:
>>
>>>
>>>
>>> * A lot of the technology in this stack is particularly old, and lacks a
>>> lot of the modern day affordances that newer things have. An example is
>>> being able to edit a discussion post to fix typos that can hinder the
>>> ability of others to actually understand whats being talked about. In your
>>> typical mailing list or IRC there?s no mechanism by which you can edit an
>>> already sent message, so your only option is to either let the problem ride
>>> and hope it doesn?t trip up too many people, or send an additional message
>>> to correct the error. However these show up as additional, later messages
>>> which someone might not even see until they?ve already been thoroughly
>>> confused by the first message (since people tend to read email/IRC in a
>>> linear fashion).
>>
>>
>> Issues, Pull Requests, Wikis, and Team Discussions are all editable.
>>
>
> Though one thing I've noticed is that a lot of issues get created and
> responded to via email clients that hide the existing message so someone
> will say "I agree" or worse, +1, and then there's 400 line of email. I
> don't know if GH has fixed the display on those things yet.
>
> FWIW.
>

There's now mobile reaction support; so you can click 'view on github' in
the email footer and thumbs up/down a message.

GitHub just added Hide and Edit comment options for maintainers:

https://blog.github.com/2018-04-18-new-tools-for-open-source-maintainers/#minimized-comments

Trimming replies is a lot of work on a mobile device:
- With a keyboard, shift-<down/right> selects complete lines
- You can also <click>, <shift>+<click> to select text

Generally, I try and follow up and clean up formatting and remove any email
signature footer after email-replying to add a comment to a GitHub issue.

There are mobile GitHub apps; though sometimes not replying until I have a
real keyboard is the better option... Far preferable to it.


>
> -W
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/53730bab/attachment.html>

From brett at python.org  Sat Apr 21 19:40:35 2018
From: brett at python.org (Brett Cannon)
Date: Sat, 21 Apr 2018 23:40:35 +0000
Subject: [Distutils] saveopts without installing?
In-Reply-To: <0B7ADE3D-0829-4DCB-963F-4BF9A0566392@gmail.com>
References: <0B7ADE3D-0829-4DCB-963F-4BF9A0566392@gmail.com>
Message-ID: <CAP1=2W5LCwO+_z4gZWWORBOQTUHAHhaPsJSPus0wnqP13WK7xQ@mail.gmail.com>

Depending on what you're after you're better off reading the wheel
metadata. If that's not an option then the answer is executing the code.

On Sat, Apr 21, 2018, 05:13 Dirk Avery, <dirk.avery at gmail.com> wrote:

> For automation project, trying to get all options set by setup.py and
> setup.cfg without actually installing. Possible?
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/078562b1/attachment.html>

From brett at python.org  Sat Apr 21 19:51:23 2018
From: brett at python.org (Brett Cannon)
Date: Sat, 21 Apr 2018 23:51:23 +0000
Subject: [Distutils] Improving Communication
In-Reply-To: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
Message-ID: <CAP1=2W4uN6i+REvFNnSzCP4dO1H5mOiw8MFaxS9Ykf5TAJ+=-w@mail.gmail.com>

I know this is no shock to Donald, but I agree with what he brings up
below. One of motivators for trying out python.zulipchat.com is to see if
it's real-time nature on top of topic-based discussion could act as a
cross-section for email and IRC.

For me, either something like Zulip or Discourse takes care of a lot of the
issues raised. They provide modern tooling, allow for a central place to
communicate, and allow for sectioning things into streams/sections to
prevent overwhelming e.g. a single mailing list.

On Fri, Apr 20, 2018, 19:08 Donald Stufft, <donald at stufft.io> wrote:

> Currently in the packaging space, we have a number of avenues for
> communication, which are:
>
> - distutils-sig
> - pypa-dev
> - virtualenv-users
> - Other project specific mailing lists
> - IRC
> - gitter
> - Various issue trackers spread across multiple platforms.
> - Probably more places I?m not remembering.
>
> The result of this is that all discussion ends up being super fractured
> amongst the various places. Sometimes that is exactly what you want (for
> instance, someone who is working on the wheel specs probably doesn?t care
> about deprecation policy and internal module renaming in pip) and sometimes
> that ends up being the opposite of what you want (for instance, when you?re
> describing something that touches PyPI, setuptools, flit, pip, etc all at
> once).
>
> Theoretically the idea is that distutils-sig is where cross project
> reaching stuff goes, IRC/gitter is where real time discussion goes, and the
> various project mailing lists and issue trackers are where the project
> specific bits go. The problem is that often times doesn?t actually happen
> in practice except for the largest and most obvious of changes.
>
> I think our current ?communications stack? kind of sucks, and I?d love to
> figure out a better way for us to handle this that solves the sort of weird
> ?independent but related? set of projects we have here.
>
> From my POV, a list of our major problems are:
>
> * Discussion gets fractured across a variety of platforms and locations,
> which can make it difficult to actually keep up with what?s going on but
> also to know how to loop in someone relevant if their input would be
> valuable. You have to more or less simultaneously know someone?s email,
> Github username, IRC nick, bitbucket username, etc to be able to bring
> threads of discussion to people?s attention.
>
> * It?s not always clear to users where a discussion should go, often times
> they?ll come to one location and need to get redirected to another
> location. If any discussion did happen in the incorrect location, it tends
> to need to get restarted in the new location (and depending on the specific
> platform, it may be impossible to actually redirect everyone over to the
> proper location, so you again, end up fractured with the discussion
> happening in two places).
>
> * A lot of the technology in this stack is particularly old, and lacks a
> lot of the modern day affordances that newer things have. An example is
> being able to edit a discussion post to fix typos that can hinder the
> ability of others to actually understand whats being talked about. In your
> typical mailing list or IRC there?s no mechanism by which you can edit an
> already sent message, so your only option is to either let the problem ride
> and hope it doesn?t trip up too many people, or send an additional message
> to correct the error. However these show up as additional, later messages
> which someone might not even see until they?ve already been thoroughly
> confused by the first message (since people tend to read email/IRC in a
> linear fashion).
>   - There is a lot of things in this one, other things are things like
> being able to control in a more fine grained manner what email you?re going
> to get.
>   - Holy crap, formatting and typography to make things actually readable
> and not a big block of plaintext.
>
> * We don?t have a clear way for users to get help, leaving users to treat
> random issues, discussion areas, etc as a support forum, rather than some
> place that?s actually optimized for that. Some of this ties back into some
> of the earlier things too, where it?s hard to actually redirect discussions
>
> These aren?t *new* problems, and often times the existing members of a
> community are the least effected becasue they?ve already spent effort
> learning the ins and outs and also curating a (typically custom) workflow
> that they?ve grown accustomed too. The problem with that is that often
> times that means that new users are left out, and the community gets
> smaller and smaller as time goes on as people leave and aren?t replaced
> with new blood, because they?re driven off but the issues with the stack.
>
> A big part of the place this is coming from, is me sitting back and
> realizing that I tend to be drawn towards pulling discussions into Github
> issues rather than onto the varying mailing lists, not because that?s
> always the most appropriate place for it, but because it?s the least
> painful place in terms of features and functionality. I figure if I?m doing
> that, when I already have a significant investment in setting up tooling
> and being involved here, that others (and particularly new users) are
> likely feeling the same way.
>
> - Donald
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/1c219d68/attachment-0001.html>

From ben+python at benfinney.id.au  Sat Apr 21 20:51:54 2018
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 22 Apr 2018 10:51:54 +1000
Subject: [Distutils] Improving Communication
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CACfEFw_r7G_SoTQZkCz4G4XQxc-iVb8hR_eWTsOW91L2i9pD8Q@mail.gmail.com>
Message-ID: <85muxwukph.fsf@benfinney.id.au>

Wes Turner <wes.turner at gmail.com> writes:

> On Friday, April 20, 2018, Donald Stufft <donald at stufft.io> wrote:
>
> > Currently in the packaging space, we have a number of avenues for
> > communication [?]
>
> GitHub Team Discussions [1]
> [?]
> - Unfortunately, they're not real time like IRC/Gitter

Another unfortunate thing about GitHub as a forum is that it's
centralised, not community-owned, and is closed for those who don't want
to have that specific gatekeeper corporation mediating their
communication with the community.

Feeding data silos is something we should be discouraging (i.e. make
effort to not go further along that path) for community-owned projects
like Python.

So, while we currently have some commitment to that particular data
silo, we should IMO not increase that and instead should move to
decentralised, community-owned platforms for community discussion.

-- 
 \       ?Facts are meaningless. You could use facts to prove anything |
  `\                that's even remotely true!? ?Homer, _The Simpsons_ |
_o__)                                                                  |
Ben Finney


From ubernostrum at gmail.com  Sat Apr 21 21:04:35 2018
From: ubernostrum at gmail.com (James Bennett)
Date: Sat, 21 Apr 2018 18:04:35 -0700
Subject: [Distutils] Improving Communication
In-Reply-To: <CAP1=2W4uN6i+REvFNnSzCP4dO1H5mOiw8MFaxS9Ykf5TAJ+=-w@mail.gmail.com>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CAP1=2W4uN6i+REvFNnSzCP4dO1H5mOiw8MFaxS9Ykf5TAJ+=-w@mail.gmail.com>
Message-ID: <CAL13Cg_E8QYb2n7Tx4d62831MZZUTmu9g7XykFycC1wsOg0Z7Q@mail.gmail.com>

Pulling in a sort-of success story from another large project, I like the
general way things happen in Django.

For developers proposing an idea or fixing a bug:

* There's IRC (#django-dev) for quick, synchronous-ish discussion, useful
for someone to find a sounding board for an idea
* There's a dev mailing list where proposals can be discussed a bit more
formally
* There's the public ticket tracker as a place to follow work being done

And for users seeking help or general discussion:

* There's IRC (#django) and a users mailing list
* There's an official-ish subreddit moderated by committers
* And there's the rest of the internet, including Stack Overflow, which we
can't moderate but which many experienced people in the community do pay
attention to

We've avoided using GitHub issues for Django, preferring the workflow tools
we get from our own customized Trac instance.

I wonder whether something similar -- a real-time chat for
discussion/sounding board/etc., mailing list to bring things to once
they've been thought about a bit, public tracker for following
work/archival purposes -- would work for packaging.

(I am also wary of too much "process"; Django has a fair bit, and more than
I'd ideally like, but my experience has been that process and participation
are generally inversely correlated)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/64ffb993/attachment.html>

From wes.turner at gmail.com  Sat Apr 21 22:21:52 2018
From: wes.turner at gmail.com (Wes Turner)
Date: Sat, 21 Apr 2018 22:21:52 -0400
Subject: [Distutils] Improving Communication
In-Reply-To: <CAL13Cg_E8QYb2n7Tx4d62831MZZUTmu9g7XykFycC1wsOg0Z7Q@mail.gmail.com>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CAP1=2W4uN6i+REvFNnSzCP4dO1H5mOiw8MFaxS9Ykf5TAJ+=-w@mail.gmail.com>
 <CAL13Cg_E8QYb2n7Tx4d62831MZZUTmu9g7XykFycC1wsOg0Z7Q@mail.gmail.com>
Message-ID: <CACfEFw98+wtmKb-QNpK0f=BoM+TWAP=-aQte8Rm0BsVqEPt9aw@mail.gmail.com>

On Saturday, April 21, 2018, James Bennett <ubernostrum at gmail.com> wrote:

> Pulling in a sort-of success story from another large project, I like the
> general way things happen in Django.
>
> For developers proposing an idea or fixing a bug:
>
> * There's IRC (#django-dev) for quick, synchronous-ish discussion, useful
> for someone to find a sounding board for an idea
>

#pypa (Freenode manages these)


> * There's a dev mailing list where proposals can be discussed a bit more
> formally
>

https://mail.python.org/mailman/listinfo/distutils-sig (still not sure who
volunteered to manage these)

https://groups.google.com/forum/m/#!forum/pypa-dev (or this)


> * There's the public ticket tracker as a place to follow work being done
>

https://github.com/pypa/setuptools/issues
https://github.com/pypa/pip/issues
https://github.com/pypa/warehouse/issues
https://github.com/pypa/twine/issues
https://github.com/pypa/virtualenv/issues

https://github.com/pypa/packaging-problems/issues



>
> And for users seeking help or general discussion:
>
> * There's IRC (#django) and a users mailing list
>

GitHub.com/pypa/<project>/new
  label: Question

#pypa
distutils-sig


> * There's an official-ish subreddit moderated by committers
> * And there's the rest of the internet, including Stack Overflow, which we
> can't moderate but which many experienced people in the community do pay
> attention to
>

https://stackoverflow.com/questions/tagged/pip
https://stackoverflow.com/questions/tagged/pypi
https://stackoverflow.com/questions/tagged/virtualenv
https://stackoverflow.com/questions/tagged/python-packaging

Thanks to the people who host and handle these questions.


> We've avoided using GitHub issues for Django, preferring the workflow
> tools we get from our own customized Trac instance.
>
> I wonder whether something similar -- a real-time chat for
> discussion/sounding board/etc., mailing list to bring things to once
> they've been thought about a bit, public tracker for following
> work/archival purposes -- would work for packaging.
>

Should there, in addition to #pypa IRC and gitter, be a zulip topic (?) for
pypa?

AFAIU, Zulip started at Dropbox, is written in Python, supports boots, and
is functionally similar to Slack, Gitter, and MatterMost?


>
> (I am also wary of too much "process"; Django has a fair bit, and more
> than I'd ideally like, but my experience has been that process and
> participation are generally inversely correlated)
>

Better yet, fork and send a pull request (PR)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180421/16dac9ba/attachment.html>

From ncoghlan at gmail.com  Sat Apr 21 23:50:15 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 22 Apr 2018 13:50:15 +1000
Subject: [Distutils] Improving Communication
In-Reply-To: <CAL13Cg_E8QYb2n7Tx4d62831MZZUTmu9g7XykFycC1wsOg0Z7Q@mail.gmail.com>
References: <505BEF3F-876B-4ADC-B81C-1DEB43CCB7C9@stufft.io>
 <CAP1=2W4uN6i+REvFNnSzCP4dO1H5mOiw8MFaxS9Ykf5TAJ+=-w@mail.gmail.com>
 <CAL13Cg_E8QYb2n7Tx4d62831MZZUTmu9g7XykFycC1wsOg0Z7Q@mail.gmail.com>
Message-ID: <CADiSq7ex10KR5gDTPpNmmu8e672vKKUzyZq46Rhsx9EKxbX0kg@mail.gmail.com>

On 22 April 2018 at 11:04, James Bennett <ubernostrum at gmail.com> wrote:
> Pulling in a sort-of success story from another large project, I like the
> general way things happen in Django.
>
> For developers proposing an idea or fixing a bug:
>
> * There's IRC (#django-dev) for quick, synchronous-ish discussion, useful
> for someone to find a sounding board for an idea
> * There's a dev mailing list where proposals can be discussed a bit more
> formally
> * There's the public ticket tracker as a place to follow work being done
>
> And for users seeking help or general discussion:
>
> * There's IRC (#django) and a users mailing list
> * There's an official-ish subreddit moderated by committers
> * And there's the rest of the internet, including Stack Overflow, which we
> can't moderate but which many experienced people in the community do pay
> attention to
>
> We've avoided using GitHub issues for Django, preferring the workflow tools
> we get from our own customized Trac instance.

Right, and this is pretty similar to the way CPython works as well
(just with Roundup in place of Trac, and without any form of official
subreddit).

The challenge for PyPA is that it's not a single project with a single
coordinated release cycle, and instead a fairly sprawling federation
of projects that we stick a single label on to indicate that we're all
working together to advance the state of the art in the Python
packaging ecosystem.

Much of that organisational complexity then gets exposed directly to
end users, since we're deliberately aiming for a model where "X is the
obvious default option, but also not your only option" across the
different parts of the stack (e.g. "X" is "pip" for package
installation, "pipenv" for application dependency management, "devpi"
for dependency caching, "twine" for artifact publication,
"setuptools-but-we're-actively-seeking-to-change-that" for artifact
creation, etc).

Something I suggested to Donald in a related discussion is that trying
to solve this kind of problem for "the PyPA" as a whole may be trying
to tackle too much complexity at once, and it may be better to instead
focus specifically on deliberately designing new communication
channels for PyPI/Warehouse.

My rationale for that suggestion was based on a few different points:

* as a production web service designed primarily for the needs of a
single instance, PyPI/Warehouse is the *least* well served of all of
PyPA's projects when it comes to the status quo (other PyPA projects
at least share the notion of "releases" and "redistributors" with
CPython)
* as a production web service, PyPI is *best* positioned of all of
PyPA's projects to guide new users to the appropriate communication
channels (now that pypi.python.org redirects to pypi.org)
* PyPI has backend web service administrators actively involved in
maintaining it, which means they're well-positioned to evaluate
options that involve running extra PSF-hosted systems or integrating
with additional external services
* Warehouse is relatively young by the standards of other components
of the ecosystem (especially relative to CPython itself), so it has
less internal community inertia to overcome (the inertia mostly exists
at the points where Warehouse interfaces with the wider Python
community, such as distutils-sig and the PEP process)

So I think if we explicitly say that we consider the Warehouse project
completely free to define communications and design processes that
work well for Warehouse *contributors*, then adopting those new
approaches can also be considered for the upcoming "PyPI download API
2.0" and "PyPI upload API 2.0" discussions, rather than requiring that
those latter discussions take place on distutils-sig. The onus would
then be on those of us that wanted to participate in the API 2.0
design discussions to adapt to the Warehouse community's chosen
toolset, rather than requiring that those discussions be restricted to
the existing toolset.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From web at stevepiercy.com  Sun Apr 22 16:19:59 2018
From: web at stevepiercy.com (Steve Piercy - Website Builder)
Date: Sun, 22 Apr 2018 13:19:59 -0700
Subject: [Distutils] Improving Communication
In-Reply-To: <CAP1=2W4uN6i+REvFNnSzCP4dO1H5mOiw8MFaxS9Ykf5TAJ+=-w@mail.gmail.com>
Message-ID: <r473Ps-10126i-60DA26F3AC41418B8B2EBB102C695139@Steves-iMac.local>

I am an email and IRC recidivist.  I have to admit that ever 
since I joined the Plone community forum which uses Discourse, I 
have been more engaged with that community than I would have 
otherwise.  I can choose which topics interest me, forget the 
rest, and explore things that might interest me at some point in 
the future.  It also has a wealth of information easily 
searchable and accessible.

I noticed that my wireless carrier uses Discourse as well, and 
I've found it exceptionally helpful to solve my phone problems 
quickly, compared to the phone manufacturer's craptastic help experience.

I haven't tried Zulip yet, but I just signed up to compare it to Discourse.

I don't know what challenges might be for self-hosting.  Perhaps 
those who have experience with self-hosting either Discourse or 
Zulip could share?

--steve


On 4/21/18 at 11:51 PM, brett at python.org (Brett Cannon) pronounced:

>I know this is no shock to Donald, but I agree with what he brings up
>below. One of motivators for trying out python.zulipchat.com is to see if
>it's real-time nature on top of topic-based discussion could act as a
>cross-section for email and IRC.
>
>For me, either something like Zulip or Discourse takes care of a lot of the
>issues raised. They provide modern tooling, allow for a central place to
>communicate, and allow for sectioning things into streams/sections to
>prevent overwhelming e.g. a single mailing list.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<web at stevepiercy.com>               <http://www.stevepiercy.com/>


From web at stevepiercy.com  Sun Apr 22 16:58:06 2018
From: web at stevepiercy.com (Steve Piercy - Website Builder)
Date: Sun, 22 Apr 2018 13:58:06 -0700
Subject: [Distutils] Improving Communication
In-Reply-To: <r473Ps-10126i-37676C0C3E8D4108A7462D85340E7ED7@Steves-iMac.local>
Message-ID: <r473Ps-10126i-C15FB200696243A98ECE48C4BCA44812@Steves-iMac.local>

My first impression of Zulip was "this feels like Slack".  It is 
visually busier than Discourse, and I had a harder time 
understanding context.  I had to step up the font twice to read 
it.  I couldn't find how to hide the user list.  I felt lost.  
Based on my first impressions, I probably wouldn't engage via Zulip.

I had a negative first impression with Discourse, too, as "yet 
another forum software", but it grew on me.  Dozens of UX 
details were done just right, like "I wonder how I can do this 
thing... oh, there it is!".  Or it could have been the Plone 
community is engaging, or a wealth of information already 
existed by the time I joined.

--steve


On 4/22/18 at 1:19 PM, web at stevepiercy.com (Steve Piercy - 
Website Builder) pronounced:

>I am an email and IRC recidivist.  I have to admit that ever 
>since I joined the Plone community forum which uses Discourse, 
>I have been more engaged with that community than I would have 
>otherwise.  I can choose which topics interest me, forget the 
>rest, and explore things that might interest me at some point 
>in the future.  It also has a wealth of information easily 
>searchable and accessible.
>
>I noticed that my wireless carrier uses Discourse as well, and 
>I've found it exceptionally helpful to solve my phone problems 
>quickly, compared to the phone manufacturer's craptastic help experience.
>
>I haven't tried Zulip yet, but I just signed up to compare it to Discourse.
>
>I don't know what challenges might be for self-hosting.  
>Perhaps those who have experience with self-hosting either 
>Discourse or Zulip could share?
>
>--steve
>
>
>On 4/21/18 at 11:51 PM, brett at python.org (Brett Cannon) pronounced:
>
>>I know this is no shock to Donald, but I agree with what he brings up
>>below. One of motivators for trying out python.zulipchat.com is to see if
>>it's real-time nature on top of topic-based discussion could act as a
>>cross-section for email and IRC.
>>
>>For me, either something like Zulip or Discourse takes care of a lot of the
>>issues raised. They provide modern tooling, allow for a central place to
>>communicate, and allow for sectioning things into streams/sections to
>>prevent overwhelming e.g. a single mailing list.
>
>-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>Steve Piercy              Website Builder              Eugene, OR
><web at stevepiercy.com>               <http://www.stevepiercy.com/>

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Steve Piercy              Website Builder              Eugene, OR
<web at stevepiercy.com>               <http://www.stevepiercy.com/>


From ncoghlan at gmail.com  Mon Apr 23 10:05:52 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Apr 2018 00:05:52 +1000
Subject: [Distutils] This list will soon be migrating to Mailman 3
Message-ID: <CADiSq7fNh1v2amdagmLrJGw6fvG1ArSTVjedbLfPwajhF1wqPQ@mail.gmail.com>

Hi folks,

The recent discussion of communication workflows prompted me to
investigate exactly what would be involved in migrating the list to
Mailman 3 (with its native web gateway and other account management
improvements), and I'm happy to report that there don't appear to be
any blockers to our initiating the migration.

I'm currently planning to send the migration request to
postmaster at python.org later this week (probably Thursday evening), but
don't have an ETA for how long the actual migration may take after
that (as I believe distutils-sig will be one of the larger python.org
list migrations undertaken so far).

Accordingly, this is an initial heads up as to exactly what the change
will mean:

1. If you only ever access the mailing list via email, and never
tinker with your subscription settings or look up threads in the list
archives, then you shouldn't notice any real changes other than some
of the headers on mails from the list changing a bit (such as the new
Archived-At header appearing on each message).

2. If you do use the website to change your subscription settings or
look up threads in the list archives, or have wished you had a more
web-forum-like interface for accessing the list, then the rest of this
email is likely to be of interest :)

== Changes to subscription management (and list moderation) ==

Mailman 3 relies on a more conventional user account management model
than the historically list-centric model in Mailman 2. This means that
either before or after the migration, folks that want to modify their
subscription settings will need to go to https://mail.python.org/mm3/
and register for an account.

If you use GitLab, GitHub, Google, or Facebook, then you can go
straight to https://mail.python.org/mm3/accounts/login/, select one of
those options, and grant the required access to look up your email
address. (At least for GitHub, the request will come from Mark
Sapiro's developer key, and I believe that's the case for the other
services as well)

If your address on the linked service matches your subscription
address, then you're done. If it doesn't match, then you can head to
https://mail.python.org/mm3/accounts/email/ to register more addresses
(and hence link any related subscriptions to your account).

If you don't use any of those services, or simply don't want to use
them with mail.python.org, then head to
https://mail.python.org/mm3/accounts/signup/ to create a conventional
username-and-password based account.

Regardless of how you sign up, the primary authentication mechanism is
access to the relevant email address - the old MM2 plain text email
password isn't used at all.

After the migration, the current
https://mail.python.org/mailman/listinfo/distutils-sig URL will
automatically redirect to
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/

For a working example of what that will look like, see
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/

== Changes to list archiving (and the native web gateway) ==

After the migration, the current list archive at
https://mail.python.org/pipermail/distutils-sig/ will remain in place
in order to preserve existing links, but will no longer be updated
with new messages. That page will also be updated with a link to the
new archiver/web gateway page.

That page will be at
https://mail.python.org/mm3/archives/list/distutils-sig at python.org/,
and not only features stable and predictable URLs for each post, but
also includes a native web gateway, allowing folks to both create new
threads and reply to existing ones using the web page, without needing
to explicitly subscribe to the list first.

Again, core-workflow provides an example of what that will look like
in practice, with the new archive at
https://mail.python.org/mm3/archives/list/core-workflow at python.org/,
and the post-migration legacy archive at
https://mail.python.org/pipermail/core-workflow/.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From dirk.avery at gmail.com  Mon Apr 23 10:05:37 2018
From: dirk.avery at gmail.com (Dirk Avery)
Date: Mon, 23 Apr 2018 10:05:37 -0400
Subject: [Distutils] saveopts without installing?
In-Reply-To: <CAP1=2W5LCwO+_z4gZWWORBOQTUHAHhaPsJSPus0wnqP13WK7xQ@mail.gmail.com>
References: <0B7ADE3D-0829-4DCB-963F-4BF9A0566392@gmail.com>
 <CAP1=2W5LCwO+_z4gZWWORBOQTUHAHhaPsJSPus0wnqP13WK7xQ@mail.gmail.com>
Message-ID: <CAH6PJezfURUS=Xbjc+0_+_NxC8QauYPU1oR3m+oMnsqAGfJ8+A@mail.gmail.com>

I think I can make that work. Easier than trying to figure out if options
are in setup.cfg or setup call. Thanks for the tip!

On Sat, Apr 21, 2018 at 7:40 PM, Brett Cannon <brett at python.org> wrote:

> Depending on what you're after you're better off reading the wheel
> metadata. If that's not an option then the answer is executing the code.
>
> On Sat, Apr 21, 2018, 05:13 Dirk Avery, <dirk.avery at gmail.com> wrote:
>
>> For automation project, trying to get all options set by setup.py and
>> setup.cfg without actually installing. Possible?
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180423/8e98411b/attachment.html>

From sh at changeset.nyc  Tue Apr 24 17:30:22 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 24 Apr 2018 17:30:22 -0400
Subject: [Distutils] PyPI update: legacy shutdown 30 April,
 new classifiers page, seeking funding
Message-ID: <1524605422.1818735.1349457952.3660C27D@webmail.messagingengine.com>

Almost the end.

On Monday April 30th we're going to shut down https://legacy.pypi.org/ .
The URL pypi.python.org will continue to redirect to Warehouse
(pypi.org). As you can see from https://status.python.org/ , Warehouse
has been holding up well, and we don't see any reason to delay the
shutdown of Legacy. If you need to compare new Warehouse behavior with
old Legacy behavior, tell us about a redirect that isn't working right,
etc., please do that this week.

Older versions of JFrog's Artifactory have trouble with the
pypi.python.org redirect. Users whose instances proxy/mirror PyPI should
upgrade before April 30th.
https://www.jfrog.com/jira/browse/RTFACT-16223?focusedCommentId=54641&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-54641
(more context[1])

We've been fixing up search[2], dealing with memory consumption[3] and
reliability, adding metrics and monitoring, replying to user issues,
reviewing volunteers' contributions, and improving PyPI admins' ability
to do things like deprecate classifiers[4]. Check out the new page
listing classifiers and linking to a search for each one!
https://pypi.org/classifiers/ And we've been working on user research
to help guide future design decisions and work. We're grateful for the
59 volunteers who have stepped up to participate in Nicole's user
tests.  And if you have a spare 5 minutes, we'd like for you to play
our "buy a feature" game via this Google form!
https://docs.google.com/forms/d/e/1FAIpQLSfABpsRcVYt7RDJEsbL_2CnyH-IKXRCRwaBhCm4sYnNI6yB3A/viewform
(short URL: bit.ly/2HpsAWd  & tweet to RT[5]) More in our weekly
meeting notes[6].

Some open issues that could use comments from you:

 * Why does warehouse allow linux_armv6l and linux_armv7l wheels?[7]
 * Derive list of classifiers from a public, version-controlled
   source[8]
 * Offer a discouraged/deprecated releases option?[9]

Thanks to jonparrott for adding sticky caching for release
descriptions[10], to contrepoint for adding a browser warning for IE
10[11], and browniebroke for customizing an email address verification
message[12].

As I said last week[13], we're running out of MOSS money. We will
probably be able to deal with any issues that come up immediately
following the legacy shutdown, but then this project (and the weekly
emails from me) will be done. Of course Warehouse could use further
sustained effort, so the Packaging Working Group has submitted some
grant proposals and requests to some funders for amounts ranging from
about USD$35,000 to about USD$150,000. Depending on the funders and
their objectives, we've mentioned chunks of work that could happen
faster (or at all) with funding, such as:
 * Adding support for two-factor authentication via TOTP and U2F/Fido.
 * Adding application-specific tokens scoped to individual
   users/projects (also covering adding token-based login support to
   twine and setuptools).
 * Adding a more advanced audit trail of user actions beyond the current
   journal (allowing publishers to track all actions taken by third-
   party services
 * on their behalf).
 * Performing accessibility repair work to follow an
   accessibility audit.
 * Researching and implementing localization and
   internationalization features.
 * Recruiting translators and integrating translations into PyPI.
We also would like to accelerate work on group/organization support[14],
better notifications, better staging/testing workflow for project
maintainers, GitHub signon, and more. If you want details on predicted
costs and are interested in hooking the Packaging Working Group[15] up
with potential funders, email cochair Ewa Jodlowska at ewa at python dot
org -- and she may advise that PSF sponsorship[16] is the route to take!
(Also if I'm wrong here about how the PSF wants to do money things,
trust actual PSF staffers and not me.)

So, things you can do:

 * check legacy.pypi.org for any behavior, links, etc. you need
 * upgrade Artifactory
 * play our "buy a feature" game
 * comment on issues that need discussion
 * help us get more funding for future work
Thanks and best wishes.
--
Sumana Harihareswara
Warehouse/PyPI project manager
Changeset Consulting
sh at changeset.nyc

Links:

   1. https://github.com/pypa/warehouse/issues/3275
   2. https://github.com/pypa/warehouse/pull/3772
   3. https://github.com/pypa/warehouse/pull/3774
   4. https://github.com/pypa/warehouse/pull/3771
   5. https://twitter.com/nlhkabu/status/988856279526465537
   6. https://wiki.python.org/psf/PackagingWG/2018-04-23-Warehouse
   7. https://github.com/pypa/warehouse/issues/3668
   8. https://github.com/pypa/warehouse/issues/3786
   9. https://github.com/pypa/warehouse/issues/3709
  10. https://github.com/pypa/warehouse/pull/3745
  11. https://github.com/pypa/warehouse/pull/3764
  12. https://github.com/pypa/warehouse/pull/3789
  13. https://groups.google.com/forum/#!topic/pypa-dev/MBa5300VlI8
  14. https://github.com/pypa/warehouse/issues/201
  15. https://wiki.python.org/psf/PackagingWG
  16. https://www.python.org/psf/sponsorship/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180424/137d89b4/attachment.html>

From sh at changeset.nyc  Tue Apr 24 17:36:13 2018
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 24 Apr 2018 17:36:13 -0400
Subject: [Distutils] PyPI update: legacy shutdown 30 April,
 new classifiers page, seeking funding
In-Reply-To: <1524605422.1818735.1349457952.3660C27D@webmail.messagingengine.com>
References: <1524605422.1818735.1349457952.3660C27D@webmail.messagingengine.com>
Message-ID: <b4b0f775-eaf0-aee1-ea08-b6f88a9e28ba@changeset.nyc>

And thanks, as ever, to Mozilla for their support for the PyPI &
Warehouse work, and to the PSF for facilitating this work!
https://pyfound.blogspot.com/2017/11/the-psf-awarded-moss-grant-pypi.html
https://blog.mozilla.org/blog/2018/01/23/moss-q4-supporting-python-ecosystem/

MOSS has a number of types of award that are open to different sorts of
open source/free software projects. If your project is looking for
financial support, check https://mozilla.org/moss to see if you qualify.
 The next application deadline is April 30th.

-Sumana

From herveberaud.pro at gmail.com  Wed Apr 25 09:00:03 2018
From: herveberaud.pro at gmail.com (herveberaud.pro at gmail.com)
Date: Wed, 25 Apr 2018 06:00:03 -0700 (PDT)
Subject: [Distutils] [improvement proposal] Manage projects with namespaces
Message-ID: <fcfd7868-257f-4c55-af37-d6903239ac29@googlegroups.com>



Hi everybody!


I want to propose an improvement to distutils and for python packaging 
management.


*Overview*


This is a feature proposal. Now when a project is already register on pypi 
it's not possible to users to test a fork of any projects with the same 
name when it's already exist, manage projects by namespace increase 
possiblities for the python community.


With this feature we can introduce trusted packages by allow install/search 
without namespace and add namespaces on untrusted packages like docker 
behavior (docker pull nginx or docker pull 4383/nginx).


On docker when the package is trusted (docker trusted image mean maintained 
by docker itself), namespace does not exist, and when a package is maintain 
by a third user namespace appear into the name.


I don't want delegate official projects maintainance to the pypa team but 
we can introduce a vote system for the community and remove namespace when 
project obtain a certain number of votes from the community (users).


I've already propose this feature to the pypa warehouse (
https://github.com/pypa/warehouse/issues/2589). Pypa team like this idea 
and we want to move forward so now we want your point of view about this.


We can formalize this feature with a PEP for describe more formerly the 
behaviors etc...


*Features* 
   
   - Allow users to vote for trust project and allow download (install, 
   search, etc...) without prefix with user namespace
   - Allow users to upload on pypi project with a name who already exist on 
   pypi but prefixed by user namespace.

*Benefits* 
   
   - Improve project trust
   - Improve package trusting and discrease risk that users deal with a 
   miscellaneous package come from a typo squatting example 1 
   <http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/index.html>, pypa github 
   discussion <https://github.com/pypa/pypi-legacy/issues/644>
   - Allow users to provide forked version of an official project
   - Allow users to test that packaging work fine on pypi

*Examples*


With pip:

$ pip install Django # trusted package
$ pip install 4383/Django # untrusted package

Url transposition:

   - https://pypi.org/project/Django/
   - https://pypi.org/project/4383/Django/

*That all folks!*


I hope this feature interesting you and you can consider this!

Do not hesitate to ask me more questions and to ask me more descriptions!

It's with pleasure that I want to help you (pypa, distutils) to implement 
this.


All the best!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180425/65aa62b4/attachment-0001.html>

From lele at metapensiero.it  Wed Apr 25 11:24:43 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Wed, 25 Apr 2018 17:24:43 +0200
Subject: [Distutils] RFH with a problem with pip 10 on Windows (AppVeyor)
Message-ID: <87zi1rtikk.fsf@metapensiero.it>

Hi,

since some time, the CI job on AppVeyor for a package I maintain fails in a
way I was not able to reproduce in my local demo Win7 VM.

This is a link to the error:

  https://ci.appveyor.com/project/lelit/python-rapidjson/build/1.0.184#L66

and as you can see, it happens when cibuildwheel tries to install the "wheel"
package, and the following happens:

  + pip install wheel
  Using default MSVC build environment for 32 bit architecture
  Executing: pip install wheel
  Traceback (most recent call last):
    File "c:\python34\lib\runpy.py", line 170, in _run_module_as_main
      "__main__", mod_spec)
    File "c:\python34\lib\runpy.py", line 85, in _run_code
      exec(code, run_globals)
    File "C:\Python34\Scripts\pip.exe\__main__.py", line 5, in <module>
  ImportError: cannot import name 'main'
  
The problem may be related to something different in version 10 of pip, but
that's just a guess: as always, on Windows there are no certainties :-)

It used to work as expected, this is a link to latest successful run:

  https://ci.appveyor.com/project/lelit/python-rapidjson/build/1.0.181?fullLog=true#L63

and since then the only (apparent) difference is the pip version...

Can anybody understand what's going on?

Thanks in advance,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.


From cosimo at anthrotype.com  Wed Apr 25 11:33:34 2018
From: cosimo at anthrotype.com (Cosimo Lupo)
Date: Wed, 25 Apr 2018 15:33:34 +0000
Subject: [Distutils] RFH with a problem with pip 10 on Windows (AppVeyor)
In-Reply-To: <87zi1rtikk.fsf@metapensiero.it>
References: <87zi1rtikk.fsf@metapensiero.it>
Message-ID: <CAPp41Btv3pMAWpi4U0iWZa23NLOWiggMA=s58n81RNeA-0Surw@mail.gmail.com>

Hello Lele,

you need to upgrade with:

python -m pip install --upgrade pip

E.g. take a look at this
https://github.com/ogrisel/python-appveyor-demo/pull/46

On Wed, Apr 25, 2018 at 4:25 PM Lele Gaifax <lele at metapensiero.it> wrote:

> Hi,
>
> since some time, the CI job on AppVeyor for a package I maintain fails in a
> way I was not able to reproduce in my local demo Win7 VM.
>
> This is a link to the error:
>
>   https://ci.appveyor.com/project/lelit/python-rapidjson/build/1.0.184#L66
>
> and as you can see, it happens when cibuildwheel tries to install the
> "wheel"
> package, and the following happens:
>
>   + pip install wheel
>   Using default MSVC build environment for 32 bit architecture
>   Executing: pip install wheel
>   Traceback (most recent call last):
>     File "c:\python34\lib\runpy.py", line 170, in _run_module_as_main
>       "__main__", mod_spec)
>     File "c:\python34\lib\runpy.py", line 85, in _run_code
>       exec(code, run_globals)
>     File "C:\Python34\Scripts\pip.exe\__main__.py", line 5, in <module>
>   ImportError: cannot import name 'main'
>
> The problem may be related to something different in version 10 of pip, but
> that's just a guess: as always, on Windows there are no certainties :-)
>
> It used to work as expected, this is a link to latest successful run:
>
>
> https://ci.appveyor.com/project/lelit/python-rapidjson/build/1.0.181?fullLog=true#L63
>
> and since then the only (apparent) difference is the pip version...
>
> Can anybody understand what's going on?
>
> Thanks in advance,
> ciao, lele.
> --
> nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
> real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
> lele at metapensiero.it  |                 -- Fortunato Depero, 1929.
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-- 
Cosimo Lupo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180425/bc98e963/attachment.html>

From lele at metapensiero.it  Wed Apr 25 12:17:26 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Wed, 25 Apr 2018 18:17:26 +0200
Subject: [Distutils] RFH with a problem with pip 10 on Windows (AppVeyor)
References: <87zi1rtikk.fsf@metapensiero.it>
 <CAPp41Btv3pMAWpi4U0iWZa23NLOWiggMA=s58n81RNeA-0Surw@mail.gmail.com>
Message-ID: <87vacftg4p.fsf@metapensiero.it>

Cosimo Lupo <cosimo at anthrotype.com> writes:

> Hello Lele,
>
> you need to upgrade with:
>
> python -m pip install --upgrade pip
>
> E.g. take a look at this
> https://github.com/ogrisel/python-appveyor-demo/pull/46

Thank you, will report to the cibuildwheel folks then.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.


From p.f.moore at gmail.com  Wed Apr 25 12:29:27 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 25 Apr 2018 17:29:27 +0100
Subject: [Distutils] RFH with a problem with pip 10 on Windows (AppVeyor)
In-Reply-To: <87vacftg4p.fsf@metapensiero.it>
References: <87zi1rtikk.fsf@metapensiero.it>
 <CAPp41Btv3pMAWpi4U0iWZa23NLOWiggMA=s58n81RNeA-0Surw@mail.gmail.com>
 <87vacftg4p.fsf@metapensiero.it>
Message-ID: <CACac1F-uB41_OXnQO=QcO216f+ZqV6W6XiVHXoPkDt0zhr5RQQ@mail.gmail.com>

On 25 April 2018 at 17:17, Lele Gaifax <lele at metapensiero.it> wrote:
> Cosimo Lupo <cosimo at anthrotype.com> writes:
>
>> Hello Lele,
>>
>> you need to upgrade with:
>>
>> python -m pip install --upgrade pip
>>
>> E.g. take a look at this
>> https://github.com/ogrisel/python-appveyor-demo/pull/46
>
> Thank you, will report to the cibuildwheel folks then.

It might be worth noting that cibuildwheel does "pip install
--disable-pip-version-check --user --upgrade pip" - see
https://github.com/joerick/cibuildwheel/blob/master/cibuildwheel/windows.py#L75

In principle this does work (i.e., it does install a correct pip.exe),
but it's likely that the location of this pip.exe is not on PATH, so
the system version is being picked up, and that's for an older version
of pip, hence the error. So an alternative to changing the command to
upgrade the system installed Python would be to ensure that the user
scripts directory is at the front of PATH. But TBH, how they choose to
fix the issue is up to the cibuildwheel project. I genuinely don't
know which option would be best for them.

Paul

From lele at metapensiero.it  Wed Apr 25 12:37:05 2018
From: lele at metapensiero.it (Lele Gaifax)
Date: Wed, 25 Apr 2018 18:37:05 +0200
Subject: [Distutils] RFH with a problem with pip 10 on Windows (AppVeyor)
References: <87zi1rtikk.fsf@metapensiero.it>
 <CAPp41Btv3pMAWpi4U0iWZa23NLOWiggMA=s58n81RNeA-0Surw@mail.gmail.com>
 <87vacftg4p.fsf@metapensiero.it>
 <CACac1F-uB41_OXnQO=QcO216f+ZqV6W6XiVHXoPkDt0zhr5RQQ@mail.gmail.com>
Message-ID: <87r2n3tf7y.fsf@metapensiero.it>

Paul Moore <p.f.moore at gmail.com> writes:

> But TBH, how they choose to fix the issue is up to the cibuildwheel
> project. I genuinely don't know which option would be best for them.

Cosimo already alerted them, and proposed this:

  https://github.com/joerick/cibuildwheel/pull/62

Let's see what happens...

thanks&bye,
lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.


From skip.montanaro at gmail.com  Wed Apr 25 16:02:01 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Wed, 25 Apr 2018 15:02:01 -0500
Subject: [Distutils] How to eliminate on part of a package?
Message-ID: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>

I recently ported a package to Python 3. The overall structure is
pretty straightforward:

top/
    client/
        module.py
    server/
        server.py

There's more to it, but that's enough for demonstration. I am
retaining Python 2.7 compatibility on the client side, but have
dispensed with that business on the server. (I run the server, not my
users.) Accordingly, I would like the py27 version of the package to
not have a subpackage named "server".

I thought it would be easy peasy to just trim the server bits from
setuptools.find_packages() in my setup.py file (I have
36.5.0.post20170921 of setuptools), something like this:

packages = setuptools.find_packages()
if sys.version_info.major < 3:
    packages.remove("top.server")

In either case, I pass the resulting list as the packages argument of
setuptools.setup(...).

That doesn't work though. I get some sort of mish-mash where part of
the top/server tree is copied, part not. I eventually get an error
from a cp command, something about ".../server is not a directory".

It would seem there is more I need to do, but nothing jumped out at me
in the online documentation
(http://setuptools.readthedocs.io/en/latest/setuptools.html). FWIW,
while I see a section on that page titled, "New and Changed setup()
Keywords", I didn't see a corresponding "Old and Unchanged setup()
Keywords" there or up a level.

Any pointers, hints, or suggestions appreciated...

Skip Montanaro

From jwodder at gmail.com  Wed Apr 25 16:08:42 2018
From: jwodder at gmail.com (John Thorvald Wodder II)
Date: Wed, 25 Apr 2018 16:08:42 -0400
Subject: [Distutils] How to eliminate on part of a package?
In-Reply-To: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
References: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
Message-ID: <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>

On 2018 Apr 25, at 16:02, Skip Montanaro <skip.montanaro at gmail.com> wrote:
> I recently ported a package to Python 3. The overall structure is
> pretty straightforward:
> 
> top/
>    client/
>        module.py
>    server/
>        server.py
> 
> There's more to it, but that's enough for demonstration. I am
> retaining Python 2.7 compatibility on the client side, but have
> dispensed with that business on the server. (I run the server, not my
> users.) Accordingly, I would like the py27 version of the package to
> not have a subpackage named "server".
> 
> I thought it would be easy peasy to just trim the server bits from
> setuptools.find_packages() in my setup.py file (I have
> 36.5.0.post20170921 of setuptools), something like this:
> 
> packages = setuptools.find_packages()
> if sys.version_info.major < 3:
>    packages.remove("top.server")
> 
> In either case, I pass the resulting list as the packages argument of
> setuptools.setup(...).
> 
> That doesn't work though. I get some sort of mish-mash where part of
> the top/server tree is copied, part not. I eventually get an error
> from a cp command, something about ".../server is not a directory".

If by "top/server tree" you mean that there are more subpackages under top.server (not just a server.py file as your diagram shows), then you need to filter out all of those subpackages as well, e.g.:

    packages = setuptools.find_packages()
    if sys.version_info.major < 3:
        packages = [
            pkg for pkg in packages
                if pkg != "top.server" and not pkg.startswith("top.server.")
        ]

From skip.montanaro at gmail.com  Wed Apr 25 16:28:41 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Wed, 25 Apr 2018 15:28:41 -0500
Subject: [Distutils] How to eliminate on part of a package?
In-Reply-To: <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>
References: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
 <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>
Message-ID: <CANc-5UxuUN_O5XbQWa8jCUE9_6efs-9LS1dw4yWCQvkw1gFrWw@mail.gmail.com>

>
> If by "top/server tree" you mean that there are more subpackages under top.server (not just a server.py file as your diagram shows), then you need to filter out all of those subpackages as well, e.g.:
>
>     packages = setuptools.find_packages()
>     if sys.version_info.major < 3:
>         packages = [
>             pkg for pkg in packages
>                 if pkg != "top.server" and not pkg.startswith("top.server.")
>         ]

Thanks, yes, there is another subpackage within top/server, but I
eliminated it as well. I was simplifying for the email. The raw
find_packages() output looks like this:

['tests', 'top', 'tests.python', 'top.client', 'top.server', 'top.server.db']

I was excising the last two elements from the returned list, so the
argument of the packages keyword looked like this:

['tests', 'top', 'tests.python', 'top.client']

Does the presence of 'top' in the list imply everything under it will
be copied (I do want 'top', as that's the top level package, not just
a directory in my repo.)

I'll keep messing with it.

Skip

From chris.barker at noaa.gov  Thu Apr 26 11:59:29 2018
From: chris.barker at noaa.gov (Chris Barker)
Date: Thu, 26 Apr 2018 08:59:29 -0700
Subject: [Distutils] How to eliminate on part of a package?
In-Reply-To: <CANc-5UxuUN_O5XbQWa8jCUE9_6efs-9LS1dw4yWCQvkw1gFrWw@mail.gmail.com>
References: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
 <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>
 <CANc-5UxuUN_O5XbQWa8jCUE9_6efs-9LS1dw4yWCQvkw1gFrWw@mail.gmail.com>
Message-ID: <CALGmxEK4oTk48dvDObsE1M-sU1hWWuwMjcjjkqkdR8wgCRGOpg@mail.gmail.com>

frankly, I'd give up n find_packages -- it's not that magic, it's just a
convenience function so you don't need to hand-specify them.

But in this case, you're doing something weird, so I"d just be explicit.

Though what I'd probably really do is make the client and server completely
separate packages. After all, you say your users only want the client side
anyway.

and if the server depends on the client (which I"d hope it doesn't!) then
you can simply make it a dependency.

-CHB




On Wed, Apr 25, 2018 at 1:28 PM, Skip Montanaro <skip.montanaro at gmail.com>
wrote:

> >
> > If by "top/server tree" you mean that there are more subpackages under
> top.server (not just a server.py file as your diagram shows), then you need
> to filter out all of those subpackages as well, e.g.:
> >
> >     packages = setuptools.find_packages()
> >     if sys.version_info.major < 3:
> >         packages = [
> >             pkg for pkg in packages
> >                 if pkg != "top.server" and not
> pkg.startswith("top.server.")
> >         ]
>
> Thanks, yes, there is another subpackage within top/server, but I
> eliminated it as well. I was simplifying for the email. The raw
> find_packages() output looks like this:
>
> ['tests', 'top', 'tests.python', 'top.client', 'top.server',
> 'top.server.db']
>
> I was excising the last two elements from the returned list, so the
> argument of the packages keyword looked like this:
>
> ['tests', 'top', 'tests.python', 'top.client']
>
> Does the presence of 'top' in the list imply everything under it will
> be copied (I do want 'top', as that's the top level package, not just
> a directory in my repo.)
>
> I'll keep messing with it.
>
> Skip
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180426/96411b73/attachment.html>

From skip.montanaro at gmail.com  Thu Apr 26 12:17:37 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Thu, 26 Apr 2018 11:17:37 -0500
Subject: [Distutils] How to eliminate on part of a package?
In-Reply-To: <CALGmxEK4oTk48dvDObsE1M-sU1hWWuwMjcjjkqkdR8wgCRGOpg@mail.gmail.com>
References: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
 <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>
 <CANc-5UxuUN_O5XbQWa8jCUE9_6efs-9LS1dw4yWCQvkw1gFrWw@mail.gmail.com>
 <CALGmxEK4oTk48dvDObsE1M-sU1hWWuwMjcjjkqkdR8wgCRGOpg@mail.gmail.com>
Message-ID: <CANc-5Uw8tXk-uiLnBxPzGs-siWM6P3RmE6ct+wYR3yoXA-JPpg@mail.gmail.com>

Yeah, splitting client and server packages is on my to-do list. Was
just hoping to keep Python2 users from shooting themselves in the foot
with a server subpackage which wouldn't work.

S

On Thu, Apr 26, 2018 at 10:59 AM, Chris Barker <chris.barker at noaa.gov> wrote:
> frankly, I'd give up n find_packages -- it's not that magic, it's just a
> convenience function so you don't need to hand-specify them.
>
> But in this case, you're doing something weird, so I"d just be explicit.
>
> Though what I'd probably really do is make the client and server completely
> separate packages. After all, you say your users only want the client side
> anyway.
>
> and if the server depends on the client (which I"d hope it doesn't!) then
> you can simply make it a dependency.
>
> -CHB
>
>
>
>
> On Wed, Apr 25, 2018 at 1:28 PM, Skip Montanaro <skip.montanaro at gmail.com>
> wrote:
>>
>> >
>> > If by "top/server tree" you mean that there are more subpackages under
>> > top.server (not just a server.py file as your diagram shows), then you need
>> > to filter out all of those subpackages as well, e.g.:
>> >
>> >     packages = setuptools.find_packages()
>> >     if sys.version_info.major < 3:
>> >         packages = [
>> >             pkg for pkg in packages
>> >                 if pkg != "top.server" and not
>> > pkg.startswith("top.server.")
>> >         ]
>>
>> Thanks, yes, there is another subpackage within top/server, but I
>> eliminated it as well. I was simplifying for the email. The raw
>> find_packages() output looks like this:
>>
>> ['tests', 'top', 'tests.python', 'top.client', 'top.server',
>> 'top.server.db']
>>
>> I was excising the last two elements from the returned list, so the
>> argument of the packages keyword looked like this:
>>
>> ['tests', 'top', 'tests.python', 'top.client']
>>
>> Does the presence of 'top' in the list imply everything under it will
>> be copied (I do want 'top', as that's the top level package, not just
>> a directory in my repo.)
>>
>> I'll keep messing with it.
>>
>> Skip
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov

From njs at pobox.com  Thu Apr 26 21:35:12 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 26 Apr 2018 18:35:12 -0700
Subject: [Distutils] How to eliminate on part of a package?
In-Reply-To: <CANc-5Uw8tXk-uiLnBxPzGs-siWM6P3RmE6ct+wYR3yoXA-JPpg@mail.gmail.com>
References: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
 <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>
 <CANc-5UxuUN_O5XbQWa8jCUE9_6efs-9LS1dw4yWCQvkw1gFrWw@mail.gmail.com>
 <CALGmxEK4oTk48dvDObsE1M-sU1hWWuwMjcjjkqkdR8wgCRGOpg@mail.gmail.com>
 <CANc-5Uw8tXk-uiLnBxPzGs-siWM6P3RmE6ct+wYR3yoXA-JPpg@mail.gmail.com>
Message-ID: <CAPJVwBkaFG88ixzOP4f8AFbA+Cu4prpX_cmSEuoRN2+59CRVvA@mail.gmail.com>

If you're lazy, you could distribute the server package to everyone
and just make sure that if someone tries to import it on python 2 then
they get a useful error.

On Thu, Apr 26, 2018 at 9:17 AM, Skip Montanaro
<skip.montanaro at gmail.com> wrote:
> Yeah, splitting client and server packages is on my to-do list. Was
> just hoping to keep Python2 users from shooting themselves in the foot
> with a server subpackage which wouldn't work.
>
> S
>
> On Thu, Apr 26, 2018 at 10:59 AM, Chris Barker <chris.barker at noaa.gov> wrote:
>> frankly, I'd give up n find_packages -- it's not that magic, it's just a
>> convenience function so you don't need to hand-specify them.
>>
>> But in this case, you're doing something weird, so I"d just be explicit.
>>
>> Though what I'd probably really do is make the client and server completely
>> separate packages. After all, you say your users only want the client side
>> anyway.
>>
>> and if the server depends on the client (which I"d hope it doesn't!) then
>> you can simply make it a dependency.
>>
>> -CHB
>>
>>
>>
>>
>> On Wed, Apr 25, 2018 at 1:28 PM, Skip Montanaro <skip.montanaro at gmail.com>
>> wrote:
>>>
>>> >
>>> > If by "top/server tree" you mean that there are more subpackages under
>>> > top.server (not just a server.py file as your diagram shows), then you need
>>> > to filter out all of those subpackages as well, e.g.:
>>> >
>>> >     packages = setuptools.find_packages()
>>> >     if sys.version_info.major < 3:
>>> >         packages = [
>>> >             pkg for pkg in packages
>>> >                 if pkg != "top.server" and not
>>> > pkg.startswith("top.server.")
>>> >         ]
>>>
>>> Thanks, yes, there is another subpackage within top/server, but I
>>> eliminated it as well. I was simplifying for the email. The raw
>>> find_packages() output looks like this:
>>>
>>> ['tests', 'top', 'tests.python', 'top.client', 'top.server',
>>> 'top.server.db']
>>>
>>> I was excising the last two elements from the returned list, so the
>>> argument of the packages keyword looked like this:
>>>
>>> ['tests', 'top', 'tests.python', 'top.client']
>>>
>>> Does the presence of 'top' in the list imply everything under it will
>>> be copied (I do want 'top', as that's the top level package, not just
>>> a directory in my repo.)
>>>
>>> I'll keep messing with it.
>>>
>>> Skip
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R            (206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115       (206) 526-6317   main reception
>>
>> Chris.Barker at noaa.gov
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig



-- 
Nathaniel J. Smith -- https://vorpus.org

From skip.montanaro at gmail.com  Fri Apr 27 06:21:04 2018
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Fri, 27 Apr 2018 10:21:04 +0000
Subject: [Distutils] How to eliminate on part of a package?
In-Reply-To: <CAPJVwBkaFG88ixzOP4f8AFbA+Cu4prpX_cmSEuoRN2+59CRVvA@mail.gmail.com>
References: <CANc-5UxPGj1zrbWvXMw4SWf6GBbSf5cLYzASRkjFvM=BqNCMwg@mail.gmail.com>
 <4229236E-F3F0-48B2-AE36-9AD618554E0F@gmail.com>
 <CANc-5UxuUN_O5XbQWa8jCUE9_6efs-9LS1dw4yWCQvkw1gFrWw@mail.gmail.com>
 <CALGmxEK4oTk48dvDObsE1M-sU1hWWuwMjcjjkqkdR8wgCRGOpg@mail.gmail.com>
 <CANc-5Uw8tXk-uiLnBxPzGs-siWM6P3RmE6ct+wYR3yoXA-JPpg@mail.gmail.com>
 <CAPJVwBkaFG88ixzOP4f8AFbA+Cu4prpX_cmSEuoRN2+59CRVvA@mail.gmail.com>
Message-ID: <CANc-5UwAN7-Yvf_Byq4ocxrJCXup68gpHPT=1eaedCTKW2pV-g@mail.gmail.com>

> If you're lazy, you could distribute the server package to everyone
> and just make sure that if someone tries to import it on python 2 then
> they get a useful error.
>

Thanks, yes, that's a good suggestion. I suspect they'd get a SyntaxError
today, but as another currently active thread suggested, that probably
would be considered more confusing than useful.

Skip

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180427/5f784dc2/attachment-0001.html>

From waynejwerner at gmail.com  Fri Apr 27 09:40:01 2018
From: waynejwerner at gmail.com (Wayne Werner)
Date: Fri, 27 Apr 2018 13:40:01 +0000
Subject: [Distutils] Improving Communication
In-Reply-To: <r473Ps-10126i-C15FB200696243A98ECE48C4BCA44812@Steves-iMac.local>
References: <r473Ps-10126i-37676C0C3E8D4108A7462D85340E7ED7@Steves-iMac.local>
 <r473Ps-10126i-C15FB200696243A98ECE48C4BCA44812@Steves-iMac.local>
Message-ID: <CAPM86NeF34_io7_6NQ-vy2MQaUOy_ZjJZwoDTdTBJvRn25V1Xg@mail.gmail.com>

On Sun, Apr 22, 2018, 4:06 PM Steve Piercy - Website Builder <
web at stevepiercy.com> wrote:

> My first impression of Zulip was "this feels like Slack".  It is
> visually busier than Discourse, and I had a harder time
> understanding context.  I had to step up the font twice to read
> it.  I couldn't find how to hide the user list.  I felt lost.
> Based on my first impressions, I probably wouldn't engage via Zulip.
>
> I had a negative first impression with Discourse, too, as "yet
> another forum software", but it grew on me.  Dozens of UX
> details were done just right, like "I wonder how I can do this
> thing... oh, there it is!".  Or it could have been the Plone
> community is engaging, or a wealth of information already
> existed by the time I joined.
>

If you weren't aware, Discourse was designed by some of the same minds
behind stack exchange. Just like they looked at QA and realized it was
broken and created Stack Overflow, they turned their sights on forum
software.

I'm sure the Plone community is fantastic, but having fantastic software
helps, too :)

-W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180427/e1a20bcd/attachment.html>

From ncoghlan at gmail.com  Sat Apr 28 00:19:23 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 28 Apr 2018 14:19:23 +1000
Subject: [Distutils] This list will soon be migrating to Mailman 3
In-Reply-To: <CADiSq7fNh1v2amdagmLrJGw6fvG1ArSTVjedbLfPwajhF1wqPQ@mail.gmail.com>
References: <CADiSq7fNh1v2amdagmLrJGw6fvG1ArSTVjedbLfPwajhF1wqPQ@mail.gmail.com>
Message-ID: <CADiSq7eB9OM2PxkBh6w7SnjR8mPMMak0DQuBTRik7B6Kea6KYw@mail.gmail.com>

On 24 April 2018 at 00:05, Nick Coghlan <ncoghlan at gmail.com> wrote:

> I'm currently planning to send the migration request to
> postmaster at python.org later this week (probably Thursday evening), but
> don't have an ETA for how long the actual migration may take after
> that (as I believe distutils-sig will be one of the larger python.org
> list migrations undertaken so far).
>

The list migration to Mailman 3 has now been requested, and is expected to
start around 1600 UTC, Sunday April 29th. Mark Sapiro will be handling the
migration for us (Thank you, Mark!).

This will be Sunday morning for the Americas and eastern Pacific, Sunday
afternoon for Europe and Africa, and then trending on towards late Sunday
night/early Monday morning for Asia and Oceania.

The migration is expected to take an hour or two, and during that time,
mails to the list may not go through, and any settings changes through the
website may not get included in the migration.

For folks that missed the original notice of the change, I've included the
details below:


> 1. If you only ever access the mailing list via email, and never
> tinker with your subscription settings or look up threads in the list
> archives, then you shouldn't notice any real changes other than some
> of the headers on mails from the list changing a bit (such as the new
> Archived-At header appearing on each message).
>
> 2. If you do use the website to change your subscription settings or
> look up threads in the list archives, or have wished you had a more
> web-forum-like interface for accessing the list, then the rest of this
> email is likely to be of interest :)
>
> == Changes to subscription management (and list moderation) ==
>
> Mailman 3 relies on a more conventional user account management model
> than the historically list-centric model in Mailman 2. This means that
> either before or after the migration, folks that want to modify their
> subscription settings will need to go to https://mail.python.org/mm3/
> and register for an account.
>
> If you use GitLab, GitHub, Google, or Facebook, then you can go
> straight to https://mail.python.org/mm3/accounts/login/, select one of
> those options, and grant the required access to look up your email
> address. (At least for GitHub, the request will come from Mark
> Sapiro's developer key, and I believe that's the case for the other
> services as well)
>
> If your address on the linked service matches your subscription
> address, then you're done. If it doesn't match, then you can head to
> https://mail.python.org/mm3/accounts/email/ to register more addresses
> (and hence link any related subscriptions to your account).
>
> If you don't use any of those services, or simply don't want to use
> them with mail.python.org, then head to
> https://mail.python.org/mm3/accounts/signup/ to create a conventional
> username-and-password based account.
>
> Regardless of how you sign up, the primary authentication mechanism is
> access to the relevant email address - the old MM2 plain text email
> password isn't used at all.
>
> After the migration, the current
> https://mail.python.org/mailman/listinfo/distutils-sig URL will
> automatically redirect to
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
>
> For a working example of what that will look like, see
> https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
>
> == Changes to list archiving (and the native web gateway) ==
>
> After the migration, the current list archive at
> https://mail.python.org/pipermail/distutils-sig/ will remain in place
> in order to preserve existing links, but will no longer be updated
> with new messages. That page will also be updated with a link to the
> new archiver/web gateway page.
>
> That page will be at
> https://mail.python.org/mm3/archives/list/distutils-sig at python.org/,
> and not only features stable and predictable URLs for each post, but
> also includes a native web gateway, allowing folks to both create new
> threads and reply to existing ones using the web page, without needing
> to explicitly subscribe to the list first.
>
> Again, core-workflow provides an example of what that will look like
> in practice, with the new archive at
> https://mail.python.org/mm3/archives/list/core-workflow at python.org/,
> and the post-migration legacy archive at
> https://mail.python.org/pipermail/core-workflow/.
>

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180428/6eccf55d/attachment.html>