Изменяет sys.path как лучший способ обработки конкретного проекта

Question

Изменяет sys.path как лучший способ обработки конкретного проекта

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

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

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

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

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

python,virtualenv,

0

Ответов: 1

питон, virtualenv,

Похожие вопросы

score 1 · Accepted Answer

1 принят

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

Использование его для производства неодобрительно (среди прочего, одна и та же переменная среды считывается как Python 2, так и 3, поэтому может возникнуть проблема, если какой-либо код в этом месте не совместим с обеими версиями), но для тестового кода, это не более необоснованно, чем настройка source /path/to/virtualenv/bin/activate.

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

Активация виртуальных bashвиртуальных оболочек - это просто вопрос запуска deactivate, а деактивация их просто выполняется activate(она добавляется в вашу оболочку как функцию при sourceредактировании сценария PYTHONPATH). Они, как правило, более безопасны, чем модификация PYTHONPATH(среди прочего, они используют подкаталоги, зависящие от версии для каждой версии майора .minor Python, поэтому вы не будете случайно запускать 3,6 конкретного кода на 2,7), но вам нужно написать свой тестовый код как реальные пакеты (с setup.pyфайлами и всеми) для правильного управления ими. Я лично думаю , что это стоит (вам необходимо изучить механизмы Python упаковки в конце концов), но это более высокий начальный навык бар.