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
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
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
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
/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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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:
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
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
21 matches
Mail list logo
