* Re: [devel] Policy по упаковке модулей Node.js
2020-02-27 21:27 [devel] Policy по упаковке модулей Node.js Vitaly Lipatov
2020-02-28 3:46 ` Anton Farygin
@ 2020-02-28 8:33 ` Скрылевъ Малъ
2020-03-03 17:01 ` Alexey Shabalin
2 siblings, 0 replies; 6+ messages in thread
From: Скрылевъ Малъ @ 2020-02-28 8:33 UTC (permalink / raw)
To: ALT Linux Team development discussions
28.02.2020, 00:28, "Vitaly Lipatov" <lav@altlinux.ru>:
> Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
> https://www.altlinux.org/Node.js_Policy
>
> Важно учитывать, что модулей для node (npm-пакетов) многие тысячи, и никакого смысла собирать в репозиторий в виде rpm-пакетов их нет, тем более невозможно учесть разницу в версиях.
> Необходимо собирать в пакеты только те модули, которые требуют компиляции (с системными библиотеками), а также модули, которые являются программами в /usr/bin (например, npm, yarn, sass, node-gyp и подобное).``
Думаю тут не нужно впрадать в крайности, типа есть модулей тычячи то и собирать их не надо. Я считаю, что каждый модуль должен быть форомблен в качестве пакет, по двум причинам:
* переиспользование модуля приложениями, и другими модулями, потому что кроме того, что есть несколько приложений, которые за собою тащат много повторяющихся модулей, но и модули этих приложений также тащат уже повторные копии тех же самых модулей, что приводит к тому,что в одном пакете приложения, я насчитаю несколько единиц копий одного и того же модуля, а для модулей нижнего уровня этот счёт по видимости может составлять десятки.
* разрешение путаницы как для наших так и для сторонних разработчиков, путаницы такой что будут обязательно вопрос почему это такой-то модуль собран отдельно а такой-то нет. А где вопросы там и смущение....
Для меня основным критерием необходимости попадания модуля в репозиторий есть тот, что, необходим ли этот самый модуль вышестоящему приложению или нет, то есть собирать модуль только потому что де он мне понравился смысла не имеет, а вот собирать его потому, что он нужен приложению, имеет.
> Программа на nodejs не является модулем для nodejs, поэтому указывать префикс, как у модуля, не требуется.
Что тут понимается под понятием программа?
Я тут бы разделил, на 2 понятие - приложение и утилита:
* приложение это любое приложение на node, зависимости запуска и работу которого определяются в том числе файлом описания проекта package.json, но при этом, оно не опубликовано на npmjs (не nodejs, такого понятия в мире node нету %) )
* утилита - собственно в некотором роде тоже программа, как правило оформленная в виде запускаемого файла, в котором в качестве интерпретатора указано node.
Ну и правила оформления такие:
для приложения это srpm имеет имя без nodejs/npmjs, целевые rpm также
для утилиты srpm может иметь префикс nodejs/npmjs, если этот фай находится в репозитории npmjs, а целевые rpm делятся на библиотеку с темже префиктом, и утилиту - без префикса, ну по типу деления в обычных компилируемых модулях, напр: soft/libsoft, дада тут префикс имеет смысл именно как в этом паре.
>Название пакета с модулем для node: nodejs-<имя>.
Я сторонник npmjs, как более понятного для внешнего разработчика знакомого с фреймворком node.
> И ассоциироваться такой префикс должен не с хранилищем (то есть с сайтом, который и поменяться может), а с названием экосистемы для пакетов, среды их исполнения.
Название хранилище может поменяться ровно в тойже степени как и само название node, так что это не очень довод. На моей памяти менялось и то и другое, причём переименование языка влечет более тяжкие последствия.
> Традиционно принято в качестве префикса использовать название языка. Так в репозитории Сизиф есть пакеты erlang-*, python-*, perl-*, ruby-*, php-* java-*. Возможно кому-то показалось, что это названия языков, на которых написаны модули. Нет, зачастую такие модули написаны на C, а не на php. И префикс имени пакета для языковых систем показывает, расширение какого языка поставляет этот пакет.
Я уже написал, что для ruby/python/erlang это недействительно
--
> С уважением,
> Виталий Липатов,
> ALT Linux Team
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
--
Малъ Скрылевъ
about.me/majioa
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [devel] Policy по упаковке модулей Node.js
2020-02-27 21:27 [devel] Policy по упаковке модулей Node.js Vitaly Lipatov
2020-02-28 3:46 ` Anton Farygin
2020-02-28 8:33 ` Скрылевъ Малъ
@ 2020-03-03 17:01 ` Alexey Shabalin
2020-03-03 17:37 ` Vitaly Lipatov
2 siblings, 1 reply; 6+ messages in thread
From: Alexey Shabalin @ 2020-03-03 17:01 UTC (permalink / raw)
To: ALT Linux Team development discussions
пт, 28 февр. 2020 г. в 00:28, Vitaly Lipatov <lav@altlinux.ru>:
>
> Хочу предложить на обсуждение полиси по упаковке модулей для Node.js:
> https://www.altlinux.org/Node.js_Policy
>
В целом нормально.
Есть вопросы:
1)
> Все пакеты npmjs паковать в rpm было бы неправильно, потому что они уже суть упакованные модули для nodejs.
> А вот пакеты для nodejs, использующие нативные библиотеки, паковать нужно обязательно, иначе невозможно обеспечить сборку бинарной части такого пакета.
Что имеется ввиду под "нативные"? библиотеки на c/c++ ?
Если да, то почему в качестве пример выбран node-webpack, в нем нет
бинарных библиотек.
2) Как использовать эти пакеты (sass, node-gyp) при сборке своих пакетов?
Я пока другого способа, как в %prep сделать симлинки, не придумал:
%prep
%setup -q
%patch -p1
ln -sf %nodejs_sitelib/node-gyp node_modules/node-gyp
ln -sf %nodejs_sitelib/node-sass node_modules/node-sass
ln -sf %nodejs_sitelib/npm node_modules/npm
Получается не совсем удобная схема.
Вот собираю я grafana.
запустил в своём бранче
yarn install --pure-lockfile
в получившемся node_modules поудалял node-sass, node-gyp, что бы потом
в %prep сделать симлинки на системные.
Может есть рекомендации, как это сделать лучше?
--
Alexey Shabalin
^ permalink raw reply [flat|nested] 6+ messages in thread