[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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1570587

Title:
  [FFe] Please update to bugfix release 20.7

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1570587

Title:
  [FFe] Please update to bugfix release 20.7

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1419695] Re: Should default to --user to not fail default pip install usage

[Donald Stufft]

We're unlikely to ship a solution within a week, however we can likely
hammer out what solution we're going to go with and probably land
something in trunk so that Ubuntu isn't different/broken it's just ahead
of the curve.

I wish y'all had reached out to us so we could have prioritized the
issue, it looks like this was decided to happen ~4 months ago which
would have been a great time to come to us and say that Ubuntu needs a
solution to this issue by X date. We haven't made a lot of progress on
the issue because it's a thorny issue with a lot of far reaching
complications and while it should be fixed it's at least not flat out
broken and the current behavior as well understood. At the same time
there were other, lower hanging fruit which were places where there were
actual broken pieces of behavior.

A side comment by someone who wasn't involved in the change is not a
great way to find out that Ubuntu broke a fairly major use case by
default, especially given that there's only a week or so to figure out a
good solution before the feature freeze. It's obviously too late to do
anything about it in this case besides us (pip) change gears and try to
quickly hammer out a solution in time. However I would suggest that
things will be better for everyone involved if engaging upstream is
treated as the first step to these things and is done early in the
process instead of being done after the fact, if at all. Doing it the
other way makes upstreams like myself feel like we have to try and
monitor all of the downstream distributors for breaking changes to try
and protect our users.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1419695

Title:
  Should default to --user to not fail default pip install usage

To manage notifications about this bug go to:
https://bugs.launchpad.net/pip/+bug/1419695/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1419695] Re: Should default to --user to not fail default pip install usage

[Donald Stufft]

Speaking as a pip core developer,  please revert this and wait for us to
fix it.

As I mentioned in a similar bug for Debian (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=725848) jumping ahead of upstream on this is going
to make things WAY worse for a lot of people. You're using a custom flag
that's only going to exist in versions of pip that comes from Ubuntu's
archive. This means that behavior is going to change drastically if end
users switch between systems or upgrade (or downgrade!) or even just
reinstall their pip through pip itself. This is going to confuse people,
it's going to break lots of tools like salt, puppet, chef, etc.

Changing this is a massively incompatible change that needs to be done
carefully and with a lot of thought about how best to do it without
causing a lot of negative impact for pip's users. Going off on your own
is only going to make a bad situation (Python packaging) that we're
slowly trying to make better a lot more confusing and a lot worse.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1419695

Title:
  Should default to --user to not fail default pip install usage

To manage notifications about this bug go to:
https://bugs.launchpad.net/pip/+bug/1419695/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1035539] Re: pip should list gcc as a dependency

[Donald Stufft]

For the record, it's totally possible to use pip without gcc. You only
need gcc if you're going to pip install something that has a C
extension.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1035539

Title:
  pip should list gcc as a dependency

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1275879] Re: Kernel panic

[Donald Stufft]

So, I don't have a problem testing this on trusty-proposed but the 5 day
thing might be an issue. The kernel panic happened randomly after some
period of time, it wasn't something I could trigger on demand. All I can
do is run a server and wait some period of time and see if it kernel
panics or not. Is that good enough?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1275879

Title:
  Kernel panic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275879/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1275879] Re: Kernel panic

[Donald Stufft]

Err, I accidently set this to Fix Released trying to click to see if
there was any information about if that meant Fix Released in the
archives or Fix Released in a 14.04.N patch and now it won't let me
change it back.

** Changed in: linux (Ubuntu Utopic)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1275879

Title:
  Kernel panic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275879/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1275879] Re: Kernel panic

[Donald Stufft]

I've tested the fix that Seth has and it resolved our issue completely.
The first time that 14.04 had been stable on our HAProxy load balancer
boxes.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1275879

Title:
  Kernel panic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275879/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1275879] Re: Kernel panic

[Donald Stufft]

We've been running this as well, however the server hasn't shut down
since we've been running it. Is the log still useful or should we wait
until it shuts down?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1275879

Title:
  Kernel panic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275879/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[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
+ 

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

[Donald Stufft]

virtualenv relies on some dirty hacks (right now at least, in the future
it'll reuse venv where available) so using venv is preferable. However
the python-virtualenv package was allowed to (at least for now, I
believe barry is planning to update it to the venv solution once it's
done) violate the Debian policy whereas the venv/ensurepip solution
wasn't. So python-virtualenv will work correctly and venv won't until
barry's work is done.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

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

[Donald Stufft]

Your use cases are correct. Ideally in the future 1) won't require
--user but that's a different discussion :)

The wheels in ensurepip are taken from PyPI and are built with ``python
setup.py bdist_wheel --no-script`` (I may have the command parameter
wrong for excluding scripts, and the latest Wheel excludes them by
default). You should be able to reproduce them by downloading the
tarball, unpacking it, and running that command. If you can't let me
know and I'll fix it. It may not be a byte for byte reproduction, I
don't know if ``setup.py bdist_wheel`` for pure python has a
deterministic output, but the contents should be the exact same.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

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

[Donald Stufft]

So I think that the debundling of requests, html5lib, etc that python-
pip does and rewheel are mutually incompatible and are going to lead to
a lot of end user pain.

Specifically the reason we bundle those things in pip is because if pip
depends on requests, and someone does ``pip install requests==1.0`` then
their pip will break and they'll have to manually uninstall requests and
manually install the correct version of requests. Specifically this
policy in pip of bundling instead of depending on has come from our
experience with our current single dependency (setuptools) and the pain
that people have had release after release where things would just
completely break unless they were very careful to do things in a
particular order. I suspect that problem would get even worse with a
dependency that other people actually depend on and not something that
most people just happen to have installed alongside their own
dependencies.

I think supporting the ability to arbitrarily install different versions
of things, even if pip itself depends on it, is important because that's
one of the primary use cases for a virtual environment.

You *could* theortically make it work by making rewheel rebundle those
things inside of pip, but you'd also need to undo the patch Debian does
to the import statements (although likely pip would just be smarter
about those instead) but the real killer there is that pip has modified
the import statments in some of those bundled modules in order to have
them import other bundled things instead of globally installed things.

In general I think the decision has to be between:

1) Treat the .whl files in ensurepip as data files, or alernatively bundled 
copies of code that are intended to be bundled (as per the Debian manual in 
4.13), and continue to do your normal modifications to python-pip.
2) Don't debundle things from python-pip (thus making you have to maintain a 
second set of patches against anything bundled) and rewheel into the venv.
3) Leave ensurepip broken and make myself and lots of Python developers sad ;(

In general my preferences are 1, 2 and a very very very very far in the
back 3. Additionally 1 matches with how python-virtualenv is treated
(which has copies of pip/setuptools in exactly the same way as
ensurepip) in that they are moved to /usr/share instead of being kept
inside of the package directory.

One *possible* solution is to install the bundled things into their own
private directory and modify sys.path inside of pip to import from
there, but I think that is going to cause a lot of bugs and broken
behavior because pip looks at sys.path to figure out what is installed
and it will probably see requests is installed and try to uninstall it
to install an upgraded version, or not install requests into the virtual
environment where others can access it because it sees requests
installed on it's sys.path.

There's also a relatively minor UX concern if 2) is the solution that
issuing a ``pip install --upgrade pip`` in a virtual environment will
get you an unmodified copy of pip so you'll end up with a slight set of
subtle differences, the most obvious being what CAs are trusted. However
some of that will hopefully be mitigated in the future by pip trying to
use the system CA certs and falling back to our own.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

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

[Donald Stufft]

I mean you can't decide not to install pip into the virtual environment
if --system-site-packages is passed to the virtual environment.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

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

[Donald Stufft]

As Barry said you can't gate installing pip on system packages or not.
Further more I would suggest that installing the OS modified pip into a
virtualenv will lead to surprising behavior for people. People should be
free to update their pip inside of a virtual environment as they wish,
however doing that will trigger people to go from a OS modified pip to
an upstream pip and can subtly change the behavior.

One thing to ensure that if you use rewheel that it should also rebundle
the bundled libraries. Pip bundles those things because otherwise we
assert what valid versions of things you can have installed alongside
pip. If you just simple install say requests into the virtual
environment alongside pip then when someone comes along and wants to
install their app which uses a different version of requests that isn't
compatible then either pip or their app breaks.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1015477] Re: pip does not verify SSL certificates

[Donald Stufft]

Hello there,

I've never particularly engaged the Linux Distro, much less the Ubuntu,
packaging process so forgive me if I'm doing this wrong.

I'm a pip maintainer and I would like to get this fixed in Ubuntu. I see
that saucy has pip 1.4.1, raring has 1.3.1, quantal has 1.1, precise has
1.0, and lucid has 0.3.1. This means that the fix is already in place
for saucy and raring but that using pip in quantal, precise, and lucid
essentially allows someone in the position to MITM traffic to execute
arbitrary Python code (ref CVE-2013-1629).

So I'm not sure what the options are for fixing this, easiest from my
point of view is to upgrade any version of pip pre 1.3 to at least pip
1.3 so that it gets TLS verification and folks are safer when using pip.
Is this an option?

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2013-1629

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1015477

Title:
  pip does not verify SSL certificates

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs