Подтвердить что ты не робот

После обновления ОС python виртуальный python с ошибкой "undefined: ошибка _PyLong_AsInt¨ на простых задачах

У меня был давно работающий virtualenv на основе python-2.7.3. После принятия рекомендуемых обновлений ОС OS (Ubuntu), которые (среди многих других изменений) принесли python до 2.7.6, питон внутри virtualenv запустил ошибку по практически всем нетривиальным задачам, причем стопки заканчиваются так:

ImportError: /home/myusername/ENVS/myvenv/lib/python2.7/lib-dynload/_io.so: undefined symbol: _PyLong_AsInt

Даже pip freeze терпит неудачу с такой ошибкой, что делает невозможным получение точной инвентаризации установленных пакетов в сломанном virtualenv (для потенциальной переустановки в новый рабочий виртуальный)!

Не следует ли защищать virtualenv от таких внешних обновлений? Или, по крайней мере, в серии 2.7.x?

4b9b3361

ОТВЕТЫ

Ответ 1

Вы можете просто сделать

cp /usr/bin/python2 /path/to/my-virtualenv/bin/python2

или

cp /usr/bin/python3 /path/to/my-virtualenv/bin/python3

Ответ 2

Virtualenv ссылается на внешнюю установку - в этом случае путь myvenv/lib/python2.7/lib-dynload на самом деле является программной ссылкой на /usr/lib/python2.7/lib-dynload, которая была обновлена. Может быть, откат назад к 2.7.3 мог бы работать?

Пробовал загружать 2,7.3 исходный код с python.org и был создан/установлен с обычными заклинаниями (даже учитывая, что это сбивает системный предпочтительный питон, риск, который я мог бы сделать с полнофункциональным снимком VM):

cd Python-2.7.3/
./configure 
make
sudo make install

По-прежнему не повезло: такая же ошибка, хотя softlink теперь указывает на ресурс на основе 2.7.3. Но как насчет копирования системы /usr/bin/python -2.7 в virtualenv? (Я не хотел этого с другой версией, но на данный момент, почему бы и нет?)

Это решило проблему. В настоящее время виртуальный рабочий работает, по крайней мере, позволяя некоторое тестирование и извлечение инвентаря "pip freeze". Конечно, внешние вещи, зависящие от 2.7.6, теперь могут быть сломаны.

И, возможно, было достаточно и безопасно просто вытащить исполняемый файл 2.2.6 python в virtualenv, чтобы заменить его сломанную версию. (Не знаю - другие ответы/ресурсы подразумевают проблемы с обновлением python внутри virtualenv, если не переустанавливать все пакеты впоследствии, хотя в основном они затрагивают неточечные версии, такие как 2.5 → 2.6.)