[Touch-packages] [Bug 1570587] Re: [FFe] Please update to bugfix release 20.7

[Donald Stufft]

That is correct. For awhile now Python has had an adhoc concept of
environment markers, but there wasn't standard for what they were and
what they supported so each implementation was slightly different (this
is a common theme with Python packaging). We attempted to standardize
this in PEP 508 which was largely compatible with the primary
implementations but wasn't 100% compatible. setuptools 20.2 switched to
the new parser, which *only* supported PEP 508 markers and not any of
the older markers, which meant that anything that relied on one of the
cases that PEP 508 no longer supported was broken. The fixes since then
restore compatability with those, and continue to keep those old
projects installable. The regressions in 20.2 were fairly major.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-setuptools in
Ubuntu.
https://bugs.launchpad.net/bugs/1570587

Title:
  [FFe] Please update to bugfix release 20.7

Status in python-setuptools package in Ubuntu:
  New

Bug description:
  In the upstream version v20.2 setuptools switched implementations of
  parser libraries. This is an internal implementation detail, however
  the new parser library did not correctly handle several edge cases
  which caused regressions preventing certain packages from installing
  or, in some cases, even running. These issues have been fixed upstream
  by versions v20.6.6 and v20.6.8. The changelog delta between what
  Ubuntu currently has an v20.7 looks like:

  v20.7.0
  ---

  * Refactored extra enviroment marker processing
in WorkingSet.
  * Issue #533: Fixed intermittent test failures.
  * Issue #536: In msvc9_support, trap additional exceptions
that might occur when importing
``distutils.msvc9compiler`` in mingw environments.
  * Issue #537: Provide better context when package
metadata fails to decode in UTF-8.

  v20.6.8
  ---

  * Issue #523: Restored support for environment markers,
now honoring 'extra' environment markers.

  v20.6.7
  ---

  * Issue #523: Disabled support for environment markers
introduced in v20.5.

  v20.6.6
  ---

  * Issue #503: Restore support for PEP 345 environment
markers by updating to Packaging 16.6.

  v20.6.0
  ---

  * New release process that relies on
`bumpversion `_
and Travis CI for continuous deployment.
  * Project versioning semantics now follow
`semver `_ precisely.
The 'v' prefix on version numbers now also allows
version numbers to be referenced in the changelog,
e.g. https://pythonhosted.org/setuptools/history.html#v20-6-0.

  20.5
  

  * BB Pull Request #185: Add support for environment markers
in requirements in install_requires, setup_requires,
tests_require as well as adding a test for the existing
extra_requires machinery.

  20.4
  

  * Issue #422: Moved hosting to
`Github `_
from `Bitbucket `_.
Issues have been migrated, though all issues and comments
are attributed to bb-migration. So if you have a particular
issue or issues to which you've been subscribed, you will
want to "watch" the equivalent issue in Github.
The Bitbucket project will be retained for the indefinite
future, but Github now hosts the canonical project repository.

  
  As you can see, v20.4 simply adjusted documentation and some release scripts 
to deal with the migration from Mercurial+Bitbucket to Git+Github and should 
have little bearing on the actual project or have much potential for 
regression. The next version, v20.5 did add a new feature, but was later 
removed in v20.6.7. v20.6.0 is another release which largely just changed 
processed and documentation without any major code changes. v20.6.1-5 are 
nonexistent, v20.6.6 is a change we want, v20.6.8 is a change we want, and 
v20.7 is some minor bugfixes and a tiny bit of refactoring.

  You can see a diff here: https://launchpadlibrarian.net/253841863
  /python-setuptools_20.3.1-1_20.7.0-1.diff.gz though it is deceptively
  larger than it actually is due to the rename of CHANGES.txt ->
  CHANGES.rst and some shuffling around of URLs and such in the
  documentation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/1570587/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1570587] [NEW] [FFe] Please update to bugfix release 20.7

[Donald Stufft]

Public bug reported:

In the upstream version v20.2 setuptools switched implementations of
parser libraries. This is an internal implementation detail, however the
new parser library did not correctly handle several edge cases which
caused regressions preventing certain packages from installing or, in
some cases, even running. These issues have been fixed upstream by
versions v20.6.6 and v20.6.8. The changelog delta between what Ubuntu
currently has an v20.7 looks like:

v20.7.0
---

* Refactored extra enviroment marker processing
  in WorkingSet.
* Issue #533: Fixed intermittent test failures.
* Issue #536: In msvc9_support, trap additional exceptions
  that might occur when importing
  ``distutils.msvc9compiler`` in mingw environments.
* Issue #537: Provide better context when package
  metadata fails to decode in UTF-8.

v20.6.8
---

* Issue #523: Restored support for environment markers,
  now honoring 'extra' environment markers.

v20.6.7
---

* Issue #523: Disabled support for environment markers
  introduced in v20.5.

v20.6.6
---

* Issue #503: Restore support for PEP 345 environment
  markers by updating to Packaging 16.6.

v20.6.0
---

* New release process that relies on
  `bumpversion `_
  and Travis CI for continuous deployment.
* Project versioning semantics now follow
  `semver `_ precisely.
  The 'v' prefix on version numbers now also allows
  version numbers to be referenced in the changelog,
  e.g. https://pythonhosted.org/setuptools/history.html#v20-6-0.

20.5


* BB Pull Request #185: Add support for environment markers
  in requirements in install_requires, setup_requires,
  tests_require as well as adding a test for the existing
  extra_requires machinery.

20.4


* Issue #422: Moved hosting to
  `Github `_
  from `Bitbucket `_.
  Issues have been migrated, though all issues and comments
  are attributed to bb-migration. So if you have a particular
  issue or issues to which you've been subscribed, you will
  want to "watch" the equivalent issue in Github.
  The Bitbucket project will be retained for the indefinite
  future, but Github now hosts the canonical project repository.


As you can see, v20.4 simply adjusted documentation and some release scripts to 
deal with the migration from Mercurial+Bitbucket to Git+Github and should have 
little bearing on the actual project or have much potential for regression. The 
next version, v20.5 did add a new feature, but was later removed in v20.6.7. 
v20.6.0 is another release which largely just changed processed and 
documentation without any major code changes. v20.6.1-5 are nonexistent, 
v20.6.6 is a change we want, v20.6.8 is a change we want, and v20.7 is some 
minor bugfixes and a tiny bit of refactoring.

You can see a diff here: https://launchpadlibrarian.net/253841863
/python-setuptools_20.3.1-1_20.7.0-1.diff.gz though it is deceptively
larger than it actually is due to the rename of CHANGES.txt ->
CHANGES.rst and some shuffling around of URLs and such in the
documentation.

** Affects: python-setuptools (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-setuptools in
Ubuntu.
https://bugs.launchpad.net/bugs/1570587

Title:
  [FFe] Please update to bugfix release 20.7

Status in python-setuptools package in Ubuntu:
  New

Bug description:
  In the upstream version v20.2 setuptools switched implementations of
  parser libraries. This is an internal implementation detail, however
  the new parser library did not correctly handle several edge cases
  which caused regressions preventing certain packages from installing
  or, in some cases, even running. These issues have been fixed upstream
  by versions v20.6.6 and v20.6.8. The changelog delta between what
  Ubuntu currently has an v20.7 looks like:

  v20.7.0
  ---

  * Refactored extra enviroment marker processing
in WorkingSet.
  * Issue #533: Fixed intermittent test failures.
  * Issue #536: In msvc9_support, trap additional exceptions
that might occur when importing
``distutils.msvc9compiler`` in mingw environments.
  * Issue #537: Provide better context when package
metadata fails to decode in UTF-8.

  v20.6.8
  ---

  * Issue #523: Restored support for environment markers,
now honoring 'extra' environment markers.

  v20.6.7
  ---

  * Issue #523: Disabled support for environment markers
introduced in v20.5.

  v20.6.6
  ---

  * Issue #503: Restore support for PEP 345 environment
markers by updating to Packaging 16.6.

  v20.6.0
  ---

  * New release process that relies on
`bumpversion `_
and Travis CI for continuous deployment.
  * Project versioning semantics now follow
`semver 

[Touch-packages] [Bug 1290847] Re: pyvenv fails due to mising ensurepip module

[Donald Stufft]

FWIW I think that ``python -m venv`` is the easiest (only?) way to
reliably say that you want to create a virtual environment for *this*
particular Python. This is especially important when multiple versions
of Python that have venv start to be able to be installed (either via
the system repos, or via PPAs like deadsnakes). In particular, there is
an inprogress rewrite of virtualenv to use the venv module for isolation
that will essentially be doing ``python -m venv``.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

Status in python3-defaults package in Ubuntu:
  Fix Released
Status in python3.4 package in Ubuntu:
  Fix Released
Status in python3.4 package in Debian:
  Fix Released

Bug description:
  Hello,

  I noticed the following

  # fails
  python3.4 -m venv --clear python-venv
  Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

  # works, but no pip
  python3.4 -m venv --clear --without-pip python-venv

  Thank you

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1290847] Re: pyvenv fails due to mising ensurepip module

[Donald Stufft]

I think it should be installed by default because it is a documented part
of the Python language. I think the Debian/Ubuntu Python is fundamentally
broken by default as it is currently.

On June 17, 2015 at 12:30:58 PM, Matthias Klose (d...@ubuntu.com) wrote:
> On 06/17/2015 06:12 PM, Donald Stufft wrote:
> > virtual environments and distro packages solve entirely different problems
> > though. They aren’t two solutions to the same problem.
>  
> if they address a different issue, the venv package doesn't need to be 
> installed
> by default.
>  
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290847
>  
> Title:
> pyvenv fails due to mising ensurepip module
>  
> Status in python3-defaults package in Ubuntu:
> Fix Released
> Status in python3.4 package in Ubuntu:
> Fix Released
> Status in python3.4 package in Debian:
> Fix Released
>  
> Bug description:
> Hello,
>  
> I noticed the following
>  
> # fails
> python3.4 -m venv --clear python-venv
> Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
> 'ensurepip',  
> '--upgrade', '--default-pip']' returned non-zero exit status 1
>  
> # works, but no pip
> python3.4 -m venv --clear --without-pip python-venv
>  
> Thank you
>  
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions
>   
>  


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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

Status in python3-defaults package in Ubuntu:
  Fix Released
Status in python3.4 package in Ubuntu:
  Fix Released
Status in python3.4 package in Debian:
  Fix Released

Bug description:
  Hello,

  I noticed the following

  # fails
  python3.4 -m venv --clear python-venv
  Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

  # works, but no pip
  python3.4 -m venv --clear --without-pip python-venv

  Thank you

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1290847] Re: pyvenv fails due to mising ensurepip module

[Donald Stufft]

virtual environments and distro packages solve entirely different problems
though. They aren’t two solutions to the same problem.

On June 17, 2015 at 12:11:28 PM, Matthias Klose (d...@ubuntu.com) wrote:
> I don't think the installation by default would be a good idea. This is
> distro land, and I think we should promote using the distro packages.
> People wanting to install venv and pip know how to do this.
>  
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1290847
>  
> Title:
> pyvenv fails due to mising ensurepip module
>  
> Status in python3-defaults package in Ubuntu:
> Fix Released
> Status in python3.4 package in Ubuntu:
> Fix Released
> Status in python3.4 package in Debian:
> Fix Released
>  
> Bug description:
> Hello,
>  
> I noticed the following
>  
> # fails
> python3.4 -m venv --clear python-venv
> Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
> 'ensurepip',  
> '--upgrade', '--default-pip']' returned non-zero exit status 1
>  
> # works, but no pip
> python3.4 -m venv --clear --without-pip python-venv
>  
> Thank you
>  
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions
>   
>  


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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

Status in python3-defaults package in Ubuntu:
  Fix Released
Status in python3.4 package in Ubuntu:
  Fix Released
Status in python3.4 package in Debian:
  Fix Released

Bug description:
  Hello,

  I noticed the following

  # fails
  python3.4 -m venv --clear python-venv
  Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

  # works, but no pip
  python3.4 -m venv --clear --without-pip python-venv

  Thank you

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1290847] Re: pyvenv fails due to mising ensurepip module

[Donald Stufft]

You can work around this by doing:

python3 -m venv --without-pip /tmp/env
curl https://bootstrap.pypa.io/get-pip.py | /tmp/env/bin/pyython

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

Status in python3-defaults package in Ubuntu:
  Fix Released
Status in python3.4 package in Ubuntu:
  Fix Released
Status in python3.4 package in Debian:
  Fix Released

Bug description:
  Hello,

  I noticed the following

  # fails
  python3.4 -m venv --clear python-venv
  Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

  # works, but no pip
  python3.4 -m venv --clear --without-pip python-venv

  Thank you

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1290847] Re: pyvenv fails due to mising ensurepip module

[Donald Stufft]

Can we just add the Wheel files to ensurepip for Trusty? It's already
being done for virtualenv (which is why it works at all) and that should
be way less impact than having to do the full backport that the other
thing would require.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

Status in “python3-defaults” package in Ubuntu:
  Fix Released
Status in “python3.4” package in Ubuntu:
  Fix Released
Status in “python3.4” package in Debian:
  Fix Released

Bug description:
  Hello,

  I noticed the following

  # fails
  python3.4 -m venv --clear python-venv
  Error: Command '['.../external/python-venv/bin/python3.4', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

  # works, but no pip
  python3.4 -m venv --clear --without-pip python-venv

  Thank you

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1365728] [NEW] SRU: pyvenv fails due to mising ensurepip module

[Donald Stufft]

Public bug reported:

[Impact]

 * Anyone attempting to use the pyenv script from Python 3.4 will be met
with a fairly confusing error by default. This would have worked fine in
saucy and raring.

 * While this can be worked around by adding a flag to the pyvenv
script, it also removes the ability to have pip installed into a pyvenv
virtualenv at all. This will prevent people from using one of the new
features that comes with Python 3.4.

 * This should be backported to the stable release because it is a major
regression in Python 3's pyvenv from previous Ubuntu releases.
Additionally it removes one of the documented features of Python 3.4.

[Test Case]

 * This can be reproduced just by doing ``python3.4 -m venv
/any/tmp/path``. You will get an error that says something like:

   Error: Command '['.../external/python-venv/bin/python3.4', '-Im',
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit
status 1

[Regression Potential]

 * I believe that the primary risk for regression will be within the
python(3)-pip packages. This is because the patches that fixed this
changed the build process there. I do not however believe that there
will be any subtle or non obvious regressions (if any at all).

[Other Info]

 * The original bug for this can be found at
https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847

 * This regression comes from the fact that in Python 3.4 an additonal
module was added to the stdlib, called ensurepip, that shipped a binary
package (a Wheel) of pip. This allowed Python to include a command
(python -m ensurepip) which would bootstrap an installation of pip into
the current environment. The venv module was then modified to use this
to install a copy of pip into the new virtual environment. The Python
package was patched to rm -rf the ensurepip module during the install
breaking the venv module in the process.

** Affects: python3.4 (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  [Impact]
  
-  * Anyone attempting to use the pyenv script from Python 3.4 will be met with
-a fairly confusing error by default. This would have worked fine in saucy
-and raring.
+  * Anyone attempting to use the pyenv script from Python 3.4 will be met
+ with a fairly confusing error by default. This would have worked fine in
+ saucy and raring.
  
-  * While this can be worked around by adding a flag to the pyvenv script, it
-also removes the ability to have pip installed into a pyvenv virtualenv at
-all. This will prevent people from using one of the new features that comes
-with Python 3.4.
+  * While this can be worked around by adding a flag to the pyvenv
+ script, it also removes the ability to have pip installed into a pyvenv
+ virtualenv at all. This will prevent people from using one of the new
+ features that comes with Python 3.4.
  
   * This should be backported to the stable release because it is a major
-regression in Python 3's pyvenv from previous Ubuntu releases. Additionally
-it removes one of the documented features of Python 3.4.
+ regression in Python 3's pyvenv from previous Ubuntu releases.
+ Additionally it removes one of the documented features of Python 3.4.
  
  [Test Case]
  
-  * This can be reproduced just by doing ``python3.4 -m venv /any/tmp/path``.
-You will get an error that says something like:
+  * This can be reproduced just by doing ``python3.4 -m venv
+ /any/tmp/path``. You will get an error that says something like:
  
 Error: Command '['.../external/python-venv/bin/python3.4', '-Im',
  'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit
  status 1
  
  [Regression Potential]
  
   * I believe that the primary risk for regression will be within the
-python(3)-pip packages. This is because the patches that fixed this changed
-the build process there. I do not however believe that there will be any
-subtle or non obvious regressions (if any at all).
+ python(3)-pip packages. This is because the patches that fixed this
+ changed the build process there. I do not however believe that there
+ will be any subtle or non obvious regressions (if any at all).
  
  [Other Info]
  
-  * The original bug for this can be found at 
https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847
-  
-  * This regression comes from the fact that in Python 3.4 an additonal module
-was added to the stdlib, called ensurepip, that shipped a binary package
-(a Wheel) of pip. This allowed Python to include a command (python -m
-ensurepip) which would bootstrap an installation of pip into the current
-environment. The venv module was then modified to use this to install a 
copy
-of pip into the new virtual environment. The Python package was patched to
-rm -rf the ensurepip module during the install breaking the venv module in
-the process.
+  * The original bug for this can be found at
+ https://bugs.launchpad.net/ubuntu/+source/py