Модификация sys.path - лучший способ обработать модуль, специфичный для проекта

Question

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

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

Для инструментов тестирования c мы используем LD_LIBRARY_PATH, чтобы указывать на наши тестовые библиотеки, либо на нашу собственную сборку библиотек, либо на какой-либо автоматический вывод сборки. Я могу изменить sys.path, чтобы включить любой каталог, который я хочу, и вести себя как LD_LIBRARY_PATH, за исключением того, что проще для моих товарищей по команде.

Это не кажется питоническим. Я знаю о virtualenv, хотя и не очень хорошо осведомлен, но у меня есть следующие проблемы:

• Хранит ли это несколько копий библиотеки или они связаны друг с другом? Размер библиотеки Python незначителен, но ИТ все еще не одобряет его с нашими очень большими репозиториями.
• связано, синхронизируются ли библиотеки, чтобы исправления ошибок были доступны для каждого инструмента?
• товарищи по команде не хотели бы запускать дополнительные команды, ./gen_test_stimulus лучше, а env LD_LIBRARY_PATH=../testlib в порядке. Несколько команд столкнутся с некоторым сопротивлением. Способ решения этой проблемы заключается в переносе команд virtualenv в сценарии bash?

Answer 1

Если это исключительно для целей тестирования, обновление вашего PYTHONPATH во время выполнения тестового кода будет примерно эквивалентно Python для обновления LD_LIBRARY_PATH для тестирования кода C. Примерно таким же образом LD_LIBRARY_PATH помещает некоторые каталоги в начало пути поиска общего объекта, PYTHONPATH перемещает определенные каталоги в начало sys.path и делает это с момента запуска Python (таким образом, вы знаете, что нет никакого странного site запускаемого импорта, который мог бы иметь место, прежде чем у вас есть время обновить sys.path в вашем основном модуле).

Использование его для производства неодобрительно (среди прочего, обе Python 2 и 3 читают одну и ту же переменную среды, поэтому это может вызвать проблемы, если какой-либо код в этом месте не совместим с обеими версиями), но для тестовый код, это не более неразумно, чем настройка LD_LIBRARY_PATH.

Виртуальные среды могут работать, но только если вы сможете каким-то образом опубликовать virtualenv в масштабах всей компании; они хранят полные копии своих локальных библиотек и (по умолчанию) предотвращают доступ к другим установленным на сайте пакетам (для обеспечения чистой среды). Virtualenv, ориентированный на тестирование, может захотеть пропустить коммутатор, который обеспечивает доступ к системным модулям, поэтому он служит дополнением к системе, а не заменой.

Активация virtualenvs в bash -подобных оболочках - это просто вопрос запуска source /path/to/virtualenv/bin/activate, а их деактивация - просто deactivate (он добавляется в вашу оболочку как функция, когда сценарий activate имеет значение source ред). Они, как правило, безопаснее, чем изменение PYTHONPATH (среди прочего, они используют подкаталоги, зависящие от версии, для каждой версии Python Major.minor, поэтому вы не будете случайно запускать специфический код 3.6 для 2.7), но вам это нужно написать свой тестовый код в виде реальных пакетов (с setup.py файлами и всеми), чтобы правильно управлять ими. Лично я думаю, что это того стоит (в конечном итоге вам нужно будет изучить механизмы упаковки Python), но - это более высокая начальная планка навыков.