В моей работе мне нужно сочетание кодов C ++, Fortran и Python для взаимодействия, в последнем случае в основном через Cython и SWIG. Они представляют собой набор широко используемых библиотек (обычно доступных через какую-то систему управления пакетами), специфичных для моей области, но не написанных мной (в основном не упакованных за пределы исходных архивов), и библиотек, для которых я являюсь разработчиком.
В течение долгого времени нам удавалось обойтись без особых беспокойств по поводу Python 3, и поэтому я управлял ~/local областью установки со смесью скомпилированного и основанного на Python2 программного обеспечения в обычном bin , lib, lib/python2.*/site-packages и т. Д. С соответствующими путями подкаталогов, включенными в переменные окружения my .bashrc PATH, LD_LIBRARY_PATH, PYTHONPATH. Но, в частности, с появлением Python 3 для машинного обучения и увеличением числа несовместимых пакетов ML, мне пришлось начать работать с каталогами virtualenv для некоторых проектов. Это, а также переход системных инструментов, таких как meld на Python 3, означают, что моя единственная глобальная среда Python 2 больше не подходит для этой цели.
В то же время я осознал, что conda и condaforge сейчас требуют большого количества соответствующего программного обеспечения. Так что теперь будут системные пакеты и версии Python, потенциально среды conda (для конкретных Pythons), пакеты pip (в virtualenvs или нет), а затем мои личные сборки. Это достаточно много для последовательной работы, и, похоже, не так много информации о наилучшей практике, особенно когда вы делитесь кодом между несколькими проектами и микшируете не-Python-библиотеки с помощью этих Python-ориентированных инструментов. Установка целой цепочки ручных зависимостей в независимой среде conda или virtualenv для каждого проекта будет очень трудной в управлении и расточительной с точки зрения дублирования больших библиотек, но, с другой стороны, кажется, по крайней мере, существует необходимость в отдельном Python 2 / 3 среды, возможно, с более специфичными для проекта virtualenvs.
Итак, набор сцен - извинения за длину, но это по сути сложно. Кто-нибудь еще борется с этой проблемой, и есть ли новый стандартный или передовой способ управления сочетаниями системных, conda, pip и ручных пакетов для разработки многих проектов без ненужного дублирования?
PS. Я ценю, что ответы могут быть в некоторой степени основаны на мнении, хотя хорошие будут доказательством и обоснованием их рекомендаций. С другой стороны, это определенно разработка программного обеспечения, а не просто управление программным обеспечением. Поэтому я надеюсь, что это подходящий вопрос для SO, так как я не вижу лучшего соответствия в сети SX.