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

В питоне есть buidout. Там можно всё своё с собой таскать. Хотя и он не лишён недостатков.

buidout -> buildout

Ok, спасибо

В ноде есть setup.py

Wheels are the new standard of python distribution. Avoids arbitrary code execution for installation. (Avoids setup.py)

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

Скорее красная тряпка

venv (который, по сути просто добавляет путь вашего проекта в начало PATH)

и позволяет держать несистемный питон. В ноде для этого нужен сторонний nvm.

Почитал ответы многоуважаемых форумчан и пришел к выводу, что некоторые преимущества у питонового подхода все-таки есть. Но в ноде все-таки правильнее

Подскажите, а как деплоить такой проект? Запихивать папку с проектом в папку с развернутым venv, и заливать все это дело на продакшн?

Э? Деплой должен быть воспроизводимым, и под этим понимают не «скопировать venv с одного из девелоперов».

В ноде обычно начинается с того, что npm run build должен выдать что-то пригодное к разворачиванию, в питонах — может быть https://packaging.python.org/tutorials/distributing-packages/#packaging-your-... но зачастую проект не имеет смысла держать в рамках npm/pip и проще собрать deb либо решить все проблемы докером.

не «скопировать venv с одного из девелоперов»

Не скопировать. Потомучто неудобно. 2 папки и странная связь между ними.

В нодах часто просто таскают папку с проектом, внутри которой неприкосновенная node_modules со всеми зависимостями. Даже на гитхабе такое видел (конечно не возьмусь утверждать что это нормальная практика, но факт остается фактом)

Хех. А в питоне при всем желании не получится папочку с venv перенести не то что на прод, а даже просто в другую папку. Скриптам в bin добавляются шебанги #!/path/to/my/venv/bin/python3

В python есть eggs и новый формат wheels. Угадай в чем цель wheels? (сам формат wheels еще в разработке). В node вообще ничего похожего на wheels нет.

В нодах часто просто таскают папку с проектом, внутри которой неприкосновенная node_modules со всеми зависимостями.

Кто?!!!

Как её будут таскать? В git её не положишь: она весит больше, чем атомная бомба. А у разных девелоперов она может быть разной.

Хех. А в питоне при всем желании не получится папочку с venv перенести не то что на прод, а даже просто в другую папку.

Вот новости. А чем я занимаюсь регулярно?

virtualenv --help в студию. И читать до просветления.

Угадай в чем цель wheels?

Кажется для того, чтобы распространять блобы

Не совсем. В частности wheel могут содержать собранные so файлы под разные платформы. Кроме того там НЕТ байткод скомпилированных файлов. Это сделано потому, что на разных платформах свои тараканы. Как ты в npm распространяешь so файлы?

Как ты в npm распространяешь so файлы?

Никак. Долгое время там вообще жесть была: V8 ABI менялся каждую версию. Разработчик node-sqlite от отчаяния написал node-pre-gyp - менеджер, который скачивает so-шку под конкретную архитектуру и версию V8. Только недавно завезли node nan - может уже и появился какой-то пакетный менеджер на его основе. Не знаю. Не слежу

И кстати перетаскивание «папочки» это совсем не та беда которая есть. Я 10 минут назад стянул с сервера virtualenv который делал 4 года назад и запустил у себя.

А потом все удалил к чертям. Угадай почему?

Вооо. А может нода складывать node_modules не в текущую «папочку», а туда куда я говорю чтоб этот node_modules был доступен для 2-3 проектов?

А потом все удалил к чертям. Угадай почему?

Понятия не имею. Не выспался?

За 5 лет основные пакеты ушли вперед. Обновить только пакеты нельзя - угадай почему

А может нода складывать node_modules не в текущую «папочку», а туда куда я говорю чтоб этот node_modules был доступен для 2-3 проектов?

Ну ради такого редкого сценария конечно стоит городить venv. И почему папочка в кавычках? Не знаю как у вас в досе с вашими «направлениями», а в моем линуксе куда не глянь - одни папочки: в Dolphin, Nautilus, etc

У нас начиная еще с незапамятных времен директория. О чем как бы говорит команда mkdir. Или каталог. Я точно помню с 80-х годов так было во всяких SYS V Unix. Да и в моем Linux: man mkdir говорит:

MKDIR(1) User Commands MKDIR(1)

NAME mkdir - make directories

SYNOPSIS mkdir [OPTION]... DIRECTORY...

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

Обычно подкручивают инсталлятор чтобы скачал готовые, или собирают на ходу если подходящего не нашлось.

А еще можно в webassembly собрать, по обстоятельствам, и будет на всех платформах одинаково. Мы подобным макаром недавно woff2 гугловский завернули, только я еще не дочистил и не опубликовал.

https://docs.npmjs.com/files/package.json

Вооо. А может нода складывать node_modules не в текущую «папочку», а туда куда я говорю чтоб этот node_modules был доступен для 2-3 проектов?

либо симлинками, либо -g

Подскажите, а как деплоить такой проект? Запихивать папку с проектом в папку с развернутым venv, и заливать все это дело на продакшн?

http://bfy.tw/GAmQ http://bfy.tw/GAmN

На сервере делаешь виртуальное окружение, которое кстати может отличаться от dev окружения. Содержимое requeirements.txt в корне проекта, в директории

project_name/requirements/

-r project_name/requirements/prod.txt

-r prod.txt

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

Очень гибко и удобно, допустим хотим переехать на django 2, создаем окружение ставим зависимости и апргейдим django до свежей версии. Что ты будешь делать с «папкой» node_modules в таком случае?

Собственно, вопрос. Почему в питоне сделано так «странно»? Дает ли это какие-то иные преимущества по сравнению с подходом в node.js? Или Гвидо просто не сообразил как сделать хорошо?

спрашиваю этот вопрос у питонщиков уже несколько лет подряд. они считают что это и есть хорошо.

Ну это от того, что небыло штатного механизма.

и в чем разница от requrements.txt ?

тут говорят это не надо

Уж точно лучше чем у ноды. Я с ней иногда копаюсь и скоро облысею. Поседеть успел. Там жабы и гадюки внутри. Сплошной содом и черти.

Шо такое -g тзь такого не знаить:

dem@demmsnt:~$ npm --help

Usage: npm <command>

where <command> is one of: add-user, adduser, apihelp, author, bin, bugs, c, cache, completion, config, ddp, dedupe, deprecate, docs, edit, explore, faq, find, find-dupes, get, help, help-search, home, i, info, init, install, isntall, issues, la, link, list, ll, ln, login, ls, outdated, owner, pack, prefix, prune, publish, r, rb, rebuild, remove, repo, restart, rm, root, run-script, s, se, search, set, show, shrinkwrap, star, stars, start, stop, submodule, tag, test, tst, un, uninstall, unlink, unpublish, unstar, up, update, v, version, view, whoami

npm <cmd> -h quick help on <cmd> npm -l display full usage info npm faq commonly asked questions npm help <term> search for help on <term> npm help npm involved overview

Specify configs in the ini-formatted file: /home/dem/.npmrc or on the command line via: npm <command> --key value Config info can be viewed via: npm help config

лучи сочувствия.

тут говорят это не надо

вполне себе надо. у нас даже в одном проекте патченый npm из-за этого.

Уж точно лучше чем у ноды.

у ноды, или у npm? сама нода не диктует, как происходит управление пакетами. у npm есть плюсы и минусы, но если сравнивать с питоновскими костылями — так минусов и вообще не найти..

Каждый кулик свое болото хвалит. Я подозреваю вы просто не умеете их готовить.

Я кстати назвал кривой случай и вы признали, что прилось патчить npm

а Maven есть у каждого джава разработчика
В джаве нет зоопарка сборщиков и репозиториев.

А еще есть Gradle. А ещё есть Ant. И первый ну очень активно продвигает тот же JetBrains и Google.

Да, у Node.js и npm всё гораздо проще, на мой взгляд.

У Python'а жуткий деплой, чего стоит только 2 vs 3 и disttools vs setuptools.

Короче, разделяю твоё мнение. Нода/npm в плане деплоя гораздо удобнее.

Я кстати назвал кривой случай и вы признали, что прилось патчить npm

я не утверждал, что этот случай не кривой, и что он не нужен.

Каждый кулик свое болото хвалит. Я подозреваю вы просто не умеете их готовить.

не умею готовить что именно?

чего стоит только 2 vs 3 и disttools vs setuptools.

А я вроде где-то вычитал что в 2.7 сделали setuptools и pip по дефолту

Не знаю, кто и что там делал, но в прошлом году я столкнулся с деплоем одного Python-скрипта, который нужно было завернуть в пакет и долго вникал, почему у меня нихрена не работает. Оказывается, всё дело в том, что distutils объявили устаревшим, вместо того, чтобы допилить его и внедрили setuptools. При этом синтаксис конфигурационного файла практически идентичный, что запутывает ещё больше. В итоге в интернете куча манов, включая оф. доки третьей ветки, где этот distutils всё ещё торчит.

Если ты не знаком со всей этой кухней, с чередой выкидываний ранее рабочих инструментов, то ты постоянно будешь натыкаться на костыли. Именно поэтому Deploy в Python боль для любого с ним несталкивающегося ранее.

В Node.js/NPM или даже YARN всё гораздо логичнее.

Жесть

В долфине тоже по правой кнопке написано «create directory», но создается папочка

жесть какая

Не знаю как у вас в досе с вашими «направлениями»,

C direction перепутал, иксперт.

Упс. Хотя гугл-переводчик и дирекцию тоже выдает вкачестве перевода)

Без понятия. Ты спросил как в ноде задаются зависимости и скрипты. Я написал как. Сравнивать с питоном и холиварить на эту тему мне не интересно. И так понятно что нода лучше :)

Ну насчет редкого случая.... Даже не знаю что сказать

Зато есть случай не столь редкий, на котором питоновая виртуальная абстракция ломается, а нода работает

user@home:~$ source test/bin/activate
(test) user@home:~$ python test.py # OK
(test) user@home:~$ sudo user=real_service_user python test.py 
Traceback (most recent call last):
  File "test.py", line 1, in <module>
    import serial
ImportError: No module named serial

Видать из-за этого и захардкожены абсолютные пути во всех скриптах в папочке my_venv/bin