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

Нода ищет node_modules не только в директории скрипта, но и во всех директориях выше.

Да, конечно же, лучше как в node.js...

Почему site-packages будет весить меньше?

Некорректное сравнение.

Zope сообщество использует easy_install В принципе те-же яйца вид сбоку.

с чередой выкидываний ранее рабочих инструментов

Полностью согласен. Эти придурки из node.js объявили bower устаревшим и я теперь должен танцевать с parcel который даже ноду мне умудрился разрушить.

И в этот момент умирает котенок. Не ну хватит вот это «папочка». Что за бред. фолдерик...

Ant давно умерло, только если какой древний легаси найти. А Gradle это в основном Android, к тому же он использует центральный репозиторий Maven и совместим с другими Maven репами.

Так я топикстартера спрашивал чтоб носом его ткнуть и он нашел 10 отличий.

Читаем маны. Думаем. Потом снова читаем маны. Думаем....

Пробовал sudo с --preserve-env - не помогло. Что еще почитать?

Хорошо скажи мне аналог pyc файлов в js?

Не вижу связи с моим вопросом, но ладно. Про js некорректно говорить. А в node.js нет аналога

Теперь в wheels попадают pyc файлы?

Ну ты ранее писал что нет. Я склонен поверить)

Хотя на главной странице: Creates .pyc files as part of installation to ensure they match the python interpreter used.

Какова причина, что pyc файлы не попадают в wheels?

Видать в разных версиях питона разный байткот

Нет в них могут попасть пути. Это фактически кэш байткода. V8 мог бы сбрасывать тоже кеш файлы, но специфика JS это не позволяет (не выгодно). Удали все pyc файлы и проверь. А перенос virtualenv вещь элементарная.

Ну и байткод тоже возможно. Тут я думаю именно так

Нет в них могут попасть пути..

А. Ну так-то да. Но то байткод. А в исходники то зачем пути захардкоживать..

А перенос virtualenv вещь элементарная

Воссоздание - элементарная, хоть и затратная. А перенос - не представляю как. абсолютный путь к там повсюду, в разных файлах

В какие конкретно? Покажи файл и кто его написал. Можно подумать идиотов в JS нет.

Еще раз:

dem@snikers:~/projects/pyroshoot$ virtualenv --help
Usage: virtualenv [OPTIONS] DEST_DIR

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         Increase verbosity.
  -q, --quiet           Decrease verbosity.
  -p PYTHON_EXE, --python=PYTHON_EXE
                        The Python interpreter to use, e.g.,
                        --python=python2.5 will use the python2.5 interpreter
                        to create the new environment.  The default is the
                        interpreter that virtualenv was installed with
                        (/usr/bin/python)
  --clear               Clear out the non-root install and start from scratch.
  --no-site-packages    DEPRECATED. Retained only for backward compatibility.
                        Not having access to global site-packages is now the
                        default behavior.
  --system-site-packages
                        Give the virtual environment access to the global
                        site-packages.
  --always-copy         Always copy files rather than symlinking.
  --unzip-setuptools    Unzip Setuptools when installing it.
  --relocatable         Make an EXISTING virtualenv environment relocatable.
                        This fixes up scripts and makes all .pth files
                        relative.
  --no-setuptools       Do not install setuptools in the new virtualenv.
  --no-pip              Do not install pip in the new virtualenv.
  --no-wheel            Do not install wheel in the new virtualenv.
  --extra-search-dir=DIR
                        Directory to look for setuptools/pip distributions in.
                        This option can be used multiple times.
  --download            Download preinstalled packages from PyPI.
  --no-download, --never-download
                        Do not download preinstalled packages from PyPI.
  --prompt=PROMPT       Provides an alternative prompt prefix for this
                        environment.
  --setuptools          DEPRECATED. Retained only for backward compatibility.
                        This option has no effect.
  --distribute          DEPRECATED. Retained only for backward compatibility.
                        This option has no effect.

Хочешь я вот просто за тебя прочту?

Я ж писал выше. pip вставляет шебанги во все исполняемые скрипты в папке bin. Плюс в activate этот путь мнго раз встречается. То-есть выходит, что папка с виртуальным окружением жестко привязана к месту ее создания

Итак:

--relocatable         Make an EXISTING virtualenv environment relocatable.
                        This fixes up scripts and makes all .pth files
                        relative.

Ну чуваак. В официальной документации написано, что virtualenv прошлый век, пользуйтесь venv

Да пофиг. Ну погляжу на venv

venv is a package shipped with Python 3, which you can run using python3 -m venv (although for some reason some distros separate it out into a separate distro package, such as python3-venv on Ubuntu/Debian). It serves a similar purpose to virtualenv, and works in a very similar way, but it doesn't need to copy Python binaries around (except on Windows). Use this if you don't need to support Python 2. At the time of writing, the Python community seems to be happy with virtualenv and I haven't heard much talk of venv.

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

Это откуда?

Да ладно. Если у человека в руках молоток он везде видит гвозди. Синдром утенка.

https://github.com/kevinconway/venvctrl

Так что... На самом деле я думаю можно и руками.

Дает ли это какие-то иные преимущества по сравнению с подходом в node.js

даёт следущие:

каталог с исходным кодом программы не содержит внутри себя кучи говна..

а вот уж ставить эту кучу говна внаружу от проета через venv/virtualenv , или например сорбать вручную через setuptools , или установить зависимости из репозитория ос ...

... — это уже решит пользователь программы, а не программист за него

Вот кстати да. Я забодался что у меня в ста каталогах node_modules. Недавно изучал vue.js У меня были каталоги vue1 vue2 и так далее. Типа каждый каталог отдельный этап развития обучения. Сначала я проклял все. Потом конечно стал лепить симлинки пока что-то не сломалось.

Именно что корректное.

Сделать пакет для NPM дело двух-трёх минут, сделать пакет c Python модулем/скриптом — нужно прочитать тонны документации, понять, чем distutils отличается от setuptools и почему distutils задепрекейчен, найти страничку «Deploying» в официальной документации https://packaging.python.org/discussions/deploying-python-applications/ увидеть, что она на 2018 год до сих пор Incomplete и FIXME.

Более наркоманского деплоя, чем в Python придумать просто невозможно. Впрочем, это типичный «Python in a nutshell», написать рабочее решение, дропнуть его, написать несовместимое с ним решение. Это как переход 2 => 3, на дворе 2018 год, а они «всё переходят».

Я просто оставлю это здесь.

В питоне если эта проблема и выражена, то в ГОРАЗДО меньшей степени.

Сделать пакет для NPM дело двух-трёх минут

1) Спорим, что я быстрее сделаю пакет Python, чем пакет NPM.

2) Сколько лет NPM?

А уж некоторые вещи в экосистемы JS заставляют тратить НЕДЕЛИ на свое решение.

Да конечно, и нечитающие документации естественным образом не порождают аццкий быдлокод.

Самому-то не смешно, чем именно агитируешь за node.js(hint: агитировать надо другим, там есть чем, я верю, ты сможешь)?

Кстати потому egg как zip вполне себе...

4.2, авторы bower сами поняли что два пакетных менеджера это перебор

Есть такое. Разрабы либ идиоты. Но npm и node_modules тут не при чем

Эти придурки из node.js объявили bower устаревшим и я теперь должен танцевать с parcel который даже ноду мне умудрился разрушить.

Вот это у тебя некорректное сравнение. Что такое bower? Что такое parcel? Это что, официальные PM для Node.js? Нет, это 3rd party. Кто их выкинул и откуда? Я заглянул сюда: https://nodejs.org/en/download/package-manager/ тут для установки всегда отмечался и требовался только NPM. Ну и https://docs.npmjs.com/getting-started/creating-node-modules соответственно. Даже видео кто-то сделал.

А теперь идём сюда: https://docs.python.org/3/library/distribution.html

WEW, distutils, везде, Legacy! Иди по внешним ссылкам, читай ещё парочку талмудов, погугли ещё, может тогда соберёшь пакетик. Вопрос, что эта хрень делает в документации? Запутывает? Почему туда сразу не включить setuptools? Потому что Python-way.

Это проблема экосистемы nodejs (и вообще js в целом), а не алгоритма поиска модулей

Zope

Оно еще живо? вау

Я агитирую за простоту и лёгкость деплоя. И это явно не про Python.

и нечитающие документации

Я ценю своё время, поэтому чтение документации, в которой утилита distutils, которой засрали весь интернет, оказывается внезапно задепрекейченной, вызывает у меня негодование.

1) Спорим, что я быстрее сделаю пакет Python, чем пакет NPM.

Бгг. Так ты варишься в этой кухне. Понимаешь, чем отличается distutils от setuptools и почему первый устарел.

Лучше скажи почему нельзя было: a) подтянуть distutils до уровня setuptools; либо, b) Официально заменить distutils на setuptools с сохранением обратной совместимости.

Вместо этого решили что? Правильно, наплодить лишних сущностей. Неосилили. Точно так же, как неосилили сохранить совместимость 2=>3 из-за которой в большинстве систем теперь тянется две ветки Python'а, а приложения который год уже переписывают на тройку.

Вообще то bower был для фронтенда.

А куда оно денется. Это совершенно гениальная штука.

Я агитирую за простоту и лёгкость деплоя. И это явно не про node.js

Был и всплыл, зачем отдельный пакетный менеджер для фронтэнда