Opened 10 years ago
Closed 10 years ago
#44612 closed defect (worksforme)
Python error while using pip with py33-virtualenv
Reported by: | Themanwithoutaplan | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.1 |
Keywords: | Cc: | jyrkiwahlstedt, stromnov (Andrey Stromnov), ned-deily (Ned Deily), petrrr | |
Port: | python33 py33-virtualenv |
Description
Not sure whether this Python or pip but I get errors when I try and use py33 virtualenvs
pip list Fatal Python error: no mem for sys.argv ValueError: character U+6573552f is not in range [U+0000; U+10ffff]
Change History (7)
comment:1 Changed 10 years ago by larryv (Lawrence Velázquez)
Cc: | jwa@… stromnov@… nad@… added |
---|---|
Keywords: | Python removed |
Port: | py33-virtualenv added; setuptools removed |
Summary: | Cannot use virtual environments with Python 3.3 → Python error while using pip with py33-virtualenv |
comment:2 Changed 10 years ago by Themanwithoutaplan
Yes, I first noticed it because tox was having difficulties on one of my projects so I just tried it in another existing environment with the same effect. py26, py27 and py34 are all fine. Strangely enough it seems to be behaving itself in a fresh folder.
comment:3 Changed 10 years ago by ned-deily (Ned Deily)
I don't recognize this specific failure mode but there are a number of possible explanations. Given that a new virtualenv does not exhibit the problem (I'm assuming that's what you mean by fresh folder), I'd think the most likely scenarios are either that: (1) the existing virtualenvs have an incompatible extension module installed (check the virtualenv's lib/python3.3
folder; or (2) (more likely) the python3.3
port was updated since the old virtualenv's were created and there is now an incompatibility between the python3.3
executable in the virtualenv bin directory and the shared standard library modules in the virtualenv lib
directory (by default, virtualenv creates symlinks to the Python framework directory). Other things to look at are settings of environment variables, in particular, LANG, LC_*, and PYTHON* ones. But, if the problem goes away by creating a new virtualenv, I'd just create new ones, perhaps using the virtualenv --always-copy
option to avoid future problems. Or use Python's built-in pyvenv
(pyenv-3.3
), the standard library's implementation of virtual envs introduced in 3.3, which avoids the symlink issues. (Also Python 3.3 is no longer being actively maintained upstream. Consider moving to Python 3.4.x).
comment:4 Changed 10 years ago by Themanwithoutaplan
I can confirm that things start to behave themselves if lib/python3.3
is removed from the relevant virtualenv. In my tox setup I found I also had to remove any relevant binaries that had found their way in from previous work.
@nad I'm already using 3.4 as my main Python but 3.3 is still being actively maintained and in any case I need to be able to run my tests across a range of platforms. I have, however, dropped support for Python 3.2
comment:5 Changed 10 years ago by ned-deily (Ned Deily)
Not to belabor the point, but note I wrote "Python 3.3 is no longer being actively maintained upstream". By upstream, I mean the CPython development project at python.org. Python 3.3.x entered security-fix only mode back in March when Python 3.4.0 was released; non-security bugs are no longer accepted or fixed for 3.3.x. See http://legacy.python.org/dev/peps/pep-0398/
comment:7 Changed 10 years ago by larryv (Lawrence Velázquez)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I’m going to assume this is not an issue that we can address.
I cannot reproduce this, but that “no mem” error looks dire.
Have you tried with other versions of Python?