Где разместить виртуальные среды?
На моем компьютере будет много виртуальных сред, и я хотел бы иметь место, где они все хранятся. Как-то $HOME и поддиры не кажутся хорошими; слишком разоблачен. Любые предложения или обоснования, почему я не ошибаюсь?
Я думаю о /var/venv/. Любые мысли?
2 ответа
Для venvs вы, вероятно, захотите, чтобы они были в подкаталоге $ HOME, чтобы избежать проблем с ограничениями безопасности в apparmor или контейнерах, таких как docker.
Обратите внимание на ограничения в этом файле:
/etc/apparmor.d/abstractions/python
Теоретически вы можете включить их / opt, но venvs действительно специфичны для пользователя и ожидаются в домашнем каталоге пользователей. Локальный не является вариантом из-за других ограничений распространения и того факта, что / usr официально предполагает совместное использование в сети с помощью LSB.
Я лично следую модифицированной версии структуры golang.
~build/
+$language/
+bin/
| venv/
| |---Python2.7
| +---Python3.6
+pkg
+src/
|
+--- my_work/..
| |---repo1
| +---other_project
|
+-- external-repo.com/..
Это позволяет легко находить и перемещать контент и совместимо с ограничениями, установленными моделями безопасности, а также другими ограничениями, которые станут более критическими, поскольку контейнеры приобретают популярность.
Запомнить что venvs были оригинальными, предназначенными для содержания в каталоге проектов. В то время как реалии основных зависимостей ОС и основных изменений версии увеличили их использование, все же предпочтительнее поддерживать их как можно ближе к отдельному пакету, процессу или пользователю.
Для venvs вы, вероятно, захотите, чтобы они были в подкаталоге $ HOME, чтобы избежать проблем с ограничениями безопасности в apparmor или контейнерах, таких как docker.
Обратите внимание на ограничения в этом файле:
/etc/apparmor.d/abstractions/python
Теоретически вы можете включить их / opt, но venvs действительно специфичны для пользователя и ожидаются в домашнем каталоге пользователей. Локальный не является вариантом из-за других ограничений распространения и того факта, что / usr официально предполагает совместное использование в сети с помощью LSB.
Я лично следую модифицированной версии структуры golang.
~build/
+$language/
+bin/
| venv/
| |---Python2.7
| +---Python3.6
+pkg
+src/
|
+--- my_work/..
| |---repo1
| +---other_project
|
+-- external-repo.com/..
Это позволяет легко находить и перемещать контент и совместимо с ограничениями, установленными моделями безопасности, а также другими ограничениями, которые станут более критическими, поскольку контейнеры приобретают популярность.
Запомнить что venvs были оригинальными, предназначенными для содержания в каталоге проектов. В то время как реалии основных зависимостей ОС и основных изменений версии увеличили их использование, все же предпочтительнее поддерживать их как можно ближе к отдельному пакету, процессу или пользователю.
-
1Хорошо, я слышу тебя, и я учусь. Не могли бы вы рассказать о безопасности, группах и других ограничениях или хотя бы предоставить некоторые ссылки? Чем больше я думаю о случаях использования, тем больше я поддерживаю его приближение к проектам. Тем не менее, я до сих пор не убежден, почему это плохая идея, когда у меня есть отдельный дир. – Dawid Laszuk 20 May 2017 в 13:46