Беспорядок с venv или новый вкус python?

Question

Вопрос

Вопрос в том, есть ли другой способ, о котором я просто не думаю, чтобы решить эти проблемы ниже, или это действительно ответ на создание аромата Python с нашими инструментами? У меня есть предложенное решение, которое решает проблемы, но это не значит, что это правильный ответ.

Проблемы

Я работаю в организации поддержки, где мы разрабатываем инструменты для поддержки нашего основного продукта. Этот продукт имеет свой собственный вид ОС, на котором он работает. У нас есть три различные проблемы, которые нужно решить в упаковке o

1. У версии ОС есть свои исходные двоичные файлы Python, в которые мы можем установить, но это ограничивает нас версией Python для ОС, которая изменится как отдельная команда, управляющая ОС. Ожидается, что это изменится в течение следующих 2 лет между выпусками 3.4, 3.5 и 3.6 Python - которые имеют изменения, которые влияют на библиотеки, которые мы используем последовательно, к лучшему и худшему.

2. Инструменты, которые мы создаем, также используются в качестве автономных инструментов на площадках без внешней связи для анализа. В настоящее время мы ограничены тем, чтобы «надеяться, что питон, который находится там, где они используют, играет хорошо».

3. Существуют значительные улучшения производительности в более поздних версиях Python, которыми мы хотели бы воспользоваться, и не можем без обновления до 3,6, но это лишает нас возможности использовать более старые версии из-за некоторых существенных различий в библиотека Python, которая разбивает вещи в одну и другую.

Мой оригинальный подход состоял в том, чтобы попытаться создать автономный virtualenv, который был бы перемещаемым, но чем больше я смотрел на этот код, тем больше я обнаруживал, что он просто редактирует PYTHONHOME и PATH, и если вы хотите, чтобы он был перемещаемым, у вас есть в любом случае скопировать все двоичные файлы, или это можно использовать только в том случае, если на хосте установлена ​​версия python, для которой вы созданы. Это также имело недостаток в том, что требовалось много изменений в сценариях virtualenv, чтобы были изменены модификации shebang, пути были обновлены и т. Д., И их нужно было обновлять при каждом движении или иметь динамические shebang.

Предлагаемое решение, которое кажется неправильным

Прямо сейчас я смотрю на создание нашего собственного "аромата" питона - но это похоже на то, как если бы на обеденной вечеринке был топор, чтобы порезать морковь. Он решает все проблемы, связанные с несколькими местами, которые могут быть использованы при наличии согласованной и обновленной версии python с установленными нами инструментами, поэтому все, что нужно пользователям, это запустить скрипт, который обновляет PATH с помощью / bin, где эти вещи установлены.

Итак, вернемся к вопросу:

Есть ли другой способ, о котором я просто не думаю, чтобы решить эти проблемы, или это действительно ответ на создание аромата Python с помощью наших инструментов? Чувствую ли я это неправильно из-за неопытности, или это правильный ответ, который я должен рассмотреть?

Answer 1

Подобно ответу Дж. Блэкадара, я знаю, по крайней мере, одну компанию, которая делает это.

Heroku, поставщик облачных услуг, имеет инструмент CLI, написанный на NodeJS. Heroku использует homebrew для распространения пакета. Они также используют тот же менеджер пакетов для распространения своей собственной версии nodejs с именем heroku / brew / node. Вы можете видеть, что иногда сама программа обновляется, и когда в NodeJS происходит обновление, они обновляют оба. Подвох в том, что иногда NodeJS сам обновляется, но heroku не обновляет свой собственный NodeJS, поэтому они могут продолжать использовать свою собственную версию, пока не запустят надлежащие тесты с новой версией.

Вы также можете установить свою собственную версию python и обновить ее отдельно или использовать virtualenv для установки конкретной версии python, но я думаю, что вы уже попробовали ее.

Другой вариант - использовать docker Конечно, у вас везде будет одна и та же среда, но это может добавить больше сложности теперь, когда у вас есть специальная ОС.

Answer 2

Я фактически закончил смешивание двух - я создал свой собственный файл «активации», который динамически распределяет путь (к чему бы ни был вызван файл активации, имеет некоторую дополнительную функциональность, и поместил это в двоичный файл Python. Когда он получен, он будет обновить шебанги.

1. Activate теперь будет устанавливать путь динамически, используя собственный каталог. что он находится как новая прокладка PATH. Это предполагает, как и с большинством venvs, что сценарий активации находится в bin.

2. Activate теперь имеет вспомогательный скрипт и оболочку, которая вызывает его для всех. файлы в мусорном ведре, у которых есть shebang. Он обновляет эти файлы путь текущего исполняемого файла Python (который должен был быть обновлен сценарием активации virtualenv на этом этапе). Будет делайте это только если шебанги разные.

Сценарий изменяется для справки:

function update_shebang() {
    # Call like: update_shebang check_sas_cabling
    full_path=${1}
    # Back up our scripts, making them hidden by default.
    file_dir=$(dirname $full_path)
    file_name=$(basename $full_path)
    cp ${full_path} "${file_dir}/.${file_name}.bak"
    # Find old shebang - will look something like this:
    # /workdir/pure_python/bin/python3
    oldbang=$(grep '#!' ${full_path})
    newbang_path=$(readlink -f `which python`)
    # We have to escape the !, but then it keeps the backslash, so we have to
    # get rid of it.
    newbang=$(echo "#\!$newbang_path" | tr -d '\\')
    # Just using sed in place
    # We dont' want to spam people every time they activate - so only modify
    # them if they aren't the same.
    if [ "$(echo $oldbang | tr -d "/")" != "$(echo $newbang | tr -d "/")" ]; then
        # Don't modify binary matches.
        if [ ! "$(echo $oldbang | grep 'Binary')" ]; then
            echo "Updated shebang for ${file_name} from ${oldbang} to ${newbang}"
            sed -i "s|${oldbang}|${newbang}|" ${full_path}
        fi
    fi
}

function update_all_shebangs() {
    # Wrapper around update_shebang to update all the
    # shebangs in ${NEW_PATH}/bin.
    given_path=$1
    myfiles=$(ls $given_path | grep -ve "^activate$")
    for file in $myfiles; do
        fullpath=$given_path/$file
        if grep -q "#!" $fullpath; then
            update_shebang $fullpath || exit 1
        fi
    done
}

И новая часть динамического пути:

NEW_PATH="$(dirname $(dirname $(readlink -f -n $BASH_SOURCE)))"

Я также включил создание этого в образ докера, который запустил все установки pip для моего требуемого материала, а затем связал его со всем этим - так что это занимает немного больше времени, но действительно перемещается во всех смыслах слова right из коробки.

Запустит репозиторий скелета, который включает это, как только я запишу сценарий установки докера, который требуется. : D

Answer 3

Вы можете фактически установить Python локально, в каталог без привилегий root, и запустить его полностью автономно от любого системного Python. Ваш инструмент может использовать эту автономную установку Python вместо любой зависимости на уровне системы.

• Распакуйте релиз Python, используя tar -xzf Python-X.X.X.tgz
• Создайте каталог для установленного Python, используя mkdir ~/python36
• Введите каталог для разархивированного установочного файла, используя cd Python-X.X.X
• Создайте make-файл Python для вашей системы, используя ./configure -prefix=/home/user/python36
• Установите Python в локальный каталог, используя make altinstall prefix=/home/user/python36 exec-prefix=/home/user/python36 (обратите внимание, что использование altinstall является критически важным, поскольку это гарантирует, что Linux-зависимость Python 2.7 или другая установленная версия не будет заменена)

Теперь вы можете запустить свой проект в этой локальной установке, используя /home/user/python36/bin/python3 script.py Используя этот метод, вы можете разрабатывать с одной версией Python, не ожидая изменений, которые вы не можете контролировать. Если вы хотите обновить ваш Python для вашего инструмента, это очень намеренное и атомарное действие.