Как следует из названия, какое технически правильное место для хранения виртуальных сред Python в операционных системах Linux в соответствии с Linux FHS?
Сформулировал еще один способ, который позволяет получить четкий ответ: «технически правильно» отделять местоположение виртуальной среды Python от файлов данных, которые вы обслуживаете?
Примечание. Этот вопрос отличается от самый близкий, уже заданный вопрос, который я мог найти, поскольку виртуальные среды содержат библиотеки, двоичные файлы, заголовочные файлы и сценарии.
В качестве дополнительной сложности я обычно пишу код, поддерживающий службы, доступные через Интернет. Однако я не вижу в этом существенного отличия моих потребностей от сценариев, в которых потребителями службы являются другие процессы на том же сервере. Я упоминаю эту деталь на тот случай, если мои ответы на комментарии будут содержать контент в стиле «веб-разработчик».
Для справки, я использую следующую документацию в качестве определения Linux FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html
Я не верю, что популярный скрипт virtualenv-wrapper предлагает правильное действие, поскольку по умолчанию он сохраняет виртуальные среды в домашнем каталоге пользователя. Это нарушает неявную концепцию о том, что каталог предназначен для пользовательских файлов, а также утверждение о том, что «ни одна программа не должна полагаться на это местоположение».
На корневом уровне файловой системы я склоняюсь к /usr (общие, только для чтения данные) или /srv ( Данные по услугам, предоставляемым этой системой), но тут я затрудняюсь определиться дальше.
Если бы я согласился с решением моего обратного прокси-сервера, это означало бы /usr. Nginx обычно упаковывается для перехода в /usr/share/nginx или /usr/local/nginx, однако /usr/ должен быть монтируется только для чтения в соответствии с FHS. Я нахожу это странным, потому что я никогда не работал над одним проектом, в котором разработка происходила бы так медленно, что «размонтировать как только для чтения/перемонтировать с записью, размонтировать/перемонтировать как только для чтения» считалось стоящим затраченных усилий.
/srv — еще одно возможное место, но указывается как " расположение файлов данных для конкретной службы», тогда как виртуальная среда Python больше ориентирована на библиотеки и двоичные файлы для того, что обеспечивает службу (без этого различия файлы .so также были бы в srv). Кроме того, несколько служб с одинаковыми требованиями могут совместно использовать виртуальную среду, что нарушает «частную» деталь описания.
Я полагаю, что отчасти трудность выбора правильного местоположения связана с тем, что виртуальная среда — это «среда», состоящая как из двоичных файлов, так и из библиотек (почти как собственная небольшая иерархия), что подталкивает меня к мысли, что где-то под /usr более традиционен. :
virtual-env/
├── bin ~= /usr/local : "for use by the system administrator when installing software locally"
├── include ~= /usr/include : "Header files included by C programs"
├── lib ~= /usr/lib : "Libraries for programming and packages"
└── share ~= /usr/local
С моими предположениями и мыслями: рассмотрим распространенный сценарий, когда Nginx действует как обратный прокси-сервер для приложения Python. Правильно ли размещать виртуальную среду и исходный код (например, application.py) под /usr/local/service_name/ при использовании /srv для файлов, которые изменяются чаще (например, «статические» активы, изображения, css)?
редактировать: Чтобы было ясно: я знаю, почему и как использовать virtualenvs. Меня ни в коем случае не смущают макеты проектов или работа в средах разработки.
