Управление сторонними библиотеками проекта в Python и Node.js. Где лучше?

В питоне pure python (*.py) зависимости ищутся начиная с каталога, в котором находится запускаемый скрипт, что-то ты выдумываешь свое. Берется список sys.path и по порядку перебираются пути, там указанные. Первым путем будет os.getcwd(), как раз текущий каталог.

Питон ищет сначала в текущем каталоге и далее по PYTHONPATH. venv делает не только это, оно ещё связывает с проектом конкретную версию интерпретатора, других утилит(pip тот же), и туда ставятся конкретные версии библиотек. venv сейчас идет с питонов в стандартной библиотеке, в чем проблема?

распространять сторонние либы с проектом не так просто.

Ты можешь их положить в текущий каталог или в другой каталог и добавить его в pythonpath в своем скрипте. Как угодно. Но достаточно сделать requirements.txt и все знают что с этим делать.

Исправил заголовок. Так лучше?

оно ещё связывает с проектом конкретную версию интерпретатора

По-моему недостаточно основательно чтобы городить для этого venv

и туда ставятся конкретные версии библиотек

В node.js для этого не требуется venv

в чем проблема?

Да нет проблем. Работает и ладно. Ну разве что куча лишних папок и файлов, появившихся в проектие из-за venv, несколько напрягают

Можешь не использовать venv. Хочешь ставь их глобально, хочешь в отдельный каталог.

куча лишних папок и файлов

npm горы всего вечно выкачивает. от того что там нет bin и lib внутри ничего не меняется.

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

Кстати, что ты будешь делать если тебе потребуются разные версии ноды на одной машине? Опять же всякие nvm понадобятся.

Можешь не использовать venv. Хочешь ставь их глобально, хочешь в отдельный каталог

Я буду делать как рекомендуют в документации. Просто вижу в питоновом подходе к сторонним либам (ИМХО) архитектурный косяк (по сравнению с нодой). Хотелось бы узнать его причины

npm горы всего вечно выкачивает. от того что там нет bin и lib внутри ничего не меняется

Да нет же. Складывает все в ~/.npm, только потом в node_modules. Как, собственно и pip в ~/.cache/pip

А как мне поможет в этом venv? Он просто делает симлинк python на (например) python3.6. Можно просто вызывать python3.6, python2.7

Кстати, что ты будешь делать если тебе потребуются разные версии ноды на одной машине?

Как мне с этим поможет venv? Она просто делает симлмнк. А разные версии питонов стоят в системе благодаря мейнтейнерам этой системы. То же самое можно сделать с нодой

Я не вижу никаких косяков. Включаешь venv и получаешь окружение с нужной версией интерпретатора по дефолту, нужными скриптами типа django-admin, нужными версиями библиотек. Окружение видит только библиотеки из своего окружения. т.е. ты можешь сделать pip install something, потом pip freeze >requirenments.txt и туда запишутся только библиотеки установленные в твоем окружении, соотв. версий.

У меня в дебиан нет питона3.6. Я его скомпилировал в /opt и при создании окружения указываю к нему путь. При активации окружения(оно прописано в pycharm и в баш можно сделать, чтобы оно автоматически включалось при переходе в каталог, если совсем лень) дефолтным интерпретатором, pip и прочим становится он.

Включаешь venv и получаешь окружение с нужной версией интерпретатора по дефолту

Городить venv только ради того, чтобы python указывал на python3.6? Не серьезно

нужными скриптами типа django-admin, нужными версиями библиотек. Окружение видит только библиотеки из своего окружения. т.е. ты можешь сделать pip install something, потом pip freeze >requirenments.txt и туда запишутся только библиотеки установленные в твоем окружении, соотв. версий

Все это умеет npm безо всяких venv благодаря всего-лишь иному подходу к поиску сторонних либ

Что значит «городить venv»? Выполнить одну команду?

только ради того

Я тебе перечислил для чего ещё.

иному подходу

Ещё раз ты можешь просто положить библиотеки в папочку и прописать её в sys.path. Можешь сделать свой велосипед pypm, если тебе venv не нравится чем-то(я так и не понял чем и что значит «городить»).

Сейчас pipenv, кстати, в моде

Я тебе перечислил для чего ещё

ИМХО не весомый аргумент. То что ты перечислил можно заменить установкой нужной версии ноды в /opt и «активацией» ее дописав в начале PATH. При этом сторонние либы будут всегда искаться в папке с проектом безо всяких venv. Я не фанат ноды и вообще жс, но реально удобнее же сделано

ты можешь просто положить библиотеки в папочку и прописать её в sys.path

Прям в исходниках? Это вообще законно? Не видел чтоб так извращались. Разве что в lua, но там от безысходности

ты можешь просто положить библиотеки в папочку и прописать её в sys.path

Прям в исходниках? Это вообще законно? Не видел чтоб так извращались. Разве что в lua

import sys
sys.path.insert(0, "/my/papochka/")

За такое мейнтейнеры, которые захотят опакетить твой проект к себе в дистрибутив, объявят на тебя охоту.

Нода, опять-же тут выигрывает: есть рядом папочка node-modules - берем либы из нее. Нет папочки - берем из системы

А меняя програмно sys.path ты меняешь стандартное поведение. Чем вызовешь много стресса у пользователей

Так что извините, но мне не понятно, почему хотя бы в pipenv (это какой уже? Четвертый пакетный менеджер?) не сделать нормально

Python просто создавался до распространяения подхода «всё своё ношу с собой», поэтому система модулей ориентирована на глобальный каталог модулей который будет управляться системным пакетным менеджером.

Так pip и pipenv появились недавно..

Ну разве что куча лишних папок и файлов, появившихся в проектие из-за venv, несколько напрягают

Оооооооооо, надеюсь ты venv в репозитории не хранишь?

Есть куча удобных инструментов для управления вирутальными окружениями. virtualenvwrapper, pyenv.

Npm та еще помойка.

До этого ещё были всякие easy_install, ну и сами правила загрузки модулей гораздо раньше были зафиксированы, venv соответственно реализует костыли чтобы из глобальных модулей сделать локальные

Есть куча удобных инструментов для управления вирутальными окружениями. virtualenvwrapper, pyenv

Я извиняюсь, но это больше напоминает кучу костылей, зародившихся по единственной причине: неэффективного алгоритма поиска сторонних либ

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

В чем неэффективность?

В том что есть «куча удобных инструментов» и куча лишних телодвижений на пустом месте

ИМХО, если в питоновский алгоритм добавить еще и поиск папочки python_modules, как в ноде. То через пару лет все забудут виртуальные среды как страшный сон

На самом деле у них обоих все очень плохо

В Python это сделано костыльно и неудобно. У ноды адекватнее.

Почему

Юзаю и python и ноду в продакшене. На ноде чуть удобнее, но один черт не принципиально. Да, в питоне есть серия костылей вокруг virtualenv. Но python передает привет из «доисторической эры» когда управление зависимостями только зарождалось.

За такое мейнтейнеры, которые захотят опакетить твой проект к себе в дистрибутив, объявят на тебя охоту.

Мейнтейнеры могут прогуляться в направлении ближайших нефритовых врат. Это им надо опакетить мой проект, а не мне.

будут всегда искаться в папке с проектом

Модули ищутся в папке с проектом в первую очередь. Если я сильно изменил какую-то библиотеку, я частенько её туда и кладу, вместо того чтобы форкать или как-то ещё изворачиваться.

Это вообще законно?

Почему нет, делал так в некоторых случаях. И видел такое в каких-то проектах.

Даже в доках это написано

https://docs.python.org/2/tutorial/modules.html#the-module-search-path

After initialization, Python programs can modify sys.path. The directory containing the script being run is placed at the beginning of the search path, ahead of the standard library path. This means that scripts in that directory will be loaded instead of modules of the same name in the library directory.

В среде лежат не только модули. Там есть bin, в котором, может быть, например django-admin и подобные скрипты, который дергает джангу нужной версии. Чтобы добиться такого же поведения придется менять PATH как-то опять же.

А могут быть ещё какие-нибудь действия в activate скрипте. Например, выставление переменных окружения. Можешь задать переменную DJANGO_SETTINGS_MODULE прямо там, например, которая часто нужна.

Node.js ищет папку node_modules

Как сделать, чтобы оно искало _node_modules?

В Python распространять сторонние либы с проектом не так просто. Приходится городить venv (который, по сути просто добавляет путь вашего проекта в начало PATH), заниматься активацией/деактивацией

Какого хрена сторонние либы вообще лежат в проекте?

Положи requirements.txt и не трахай людям мозг. Можешь pip download -r requirements.txt ещё сделать, если шило в жопе.

В джаве лучше

Оба варианта убогие.

Чем? Подробнее можно?

Гхм. Сегодня как раз имел дело с нодой и проклял все. Вообще нормальные люди оформляют свой проект в виде пакета и ставят его через pip install ВСЕ.

Цель venv СОВСЕМ не для этого. venv нужен ДЛЯ РАЗРАБОТКИ.

Сразу видно знатока. В Python с зависимостями все прекрасно. Даже лучше чем в ноде. В ноде есть setup.py ?

Расскажи как в пакете ноды ты описываешь зависимости?

есть рядом папочка

Кстати «папочка» это лакмусовая бумажка.

Собственно, вопрос. Почему в питоне сделано так «странно»?

потому что у тебя нодажс головного мозга

Итак, топик прочитал и не понял, почему лоровские эксперты используют venv, когда есть божественный virtualenv (sudo apt install python-virtualenv) ???? В продакшене тож venv используете?

В продакшене

Тяп-ляп, и в докер. //c: La Veranda

Это получается на сервер ставится только докер а все остальное nginx, mysql, python, уже внутри докера?

Чем? Подробнее можно?

Там есть Maven, а Maven есть у каждого джава разработчика. Добавляешь название библиотеки в pom.xml и всё. Можешь не переживать, что у кого-то проект не соберется и не писать README по сборке проекта. И не таскать сторонние библиотеки с проектом.

Про машину разработчика ясно. Но как maven сочетается с системным пакетным менеджером? Они же друг про друга ничего не знают

Просто JavaScript самый лучший в мире язык программирования.

Никак не сочетаются. В джаве нет зоопарка сборщиков и репозиториев. Есть центральный Maven репозиторий, все им пользуются. Репами Debian или Red Hat пользуются только при установке какого-нибудь Tomcat'a, но подобное редкость. Так что если у тебя на машине есть джава сырцы, то где-то рядом должен быть Maven сборщик.

Если же речь про конечную доставку пользователю, то всё компилируется в архив, со всеми сторонними библиотеками и распространяется как любые другие бинарники.

Где лучше?

Эскобар.жипег