Source0 for nodejs modules
by Piotr Popieluch
The the Node.js guidelines say about Source0 [1]:
"The canonical method for shipping most node modules is tarballs from
the npm registry"
and
"This method [PP: tarbals from npm] should be preferred to using
checkouts from git or automatically generated tarballs from GitHub."
But I think that in following cases it would be better to use sources
from the upstream project:
1) When the license is not included in NPM but is in upstream project.
o Because we are not supposed to ship the license separate from the
sources.
2) When the tests are not included.
o In this case we need to download the sources from NPM and from
upstream project, which seems redundant and a waste of work.
3) When NPM content is generated and source files are not in NPM.
o This would mean to download sources from NPM and upstream project,
delete the NPM sources in prep and generate the files again.
Are there good reason to enforce the use of NPM sources which I am
missing? What is your opinion?
I would like to suggest to ad those three exceptions to the guidelines.
Piotr
[1]:
https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Usi...
5 years, 4 months
Packaging the Javascript layer of Prometheus & Grafana
by Nicolas Mailhot
Hi,
I'm currently investigating the packaging of Prometheus and Grafana in
Fedora/Epel.
Both are cutting-edge high-visibility complex applications written in
Go, that map well to Fedora/Epel historical sysadmin userbase
https://prometheus.io/
https://grafana.com/
I already spent a few months of work working on the Go layer, writing
Golang-to-rpm plumbing, packaging guidelines, packaging and testing
hundreds of spec files. It is finally looking like something that could
end up in the distribution, even though there is still a ton of work to
do plumbing-side to make Go packaging in Fedora simple and convenient.
And I'd like to spend more time making this plumbing a reality.
However, at the same time, the target apps can not be used, since they
include a javascript layer, and I haven't packaged it.
Prometheus provides a bundled copy of the javascript it needs, thus I
supposed it could be packaged as-is, even though that is bad engineering
and totally not what I did for the Go layer.
https://github.com/prometheus/prometheus/tree/master/web/ui/static/vendor
Grafana OTOH has a clean codebase with a build process that uses yarn to
get third-party javascript
https://github.com/grafana/grafana/blob/master/yarn.lock
Therefore, I'm looking for help :
1. either pointers or advice on how to package this javascript cleanly
or
2. ideally, people willing to take over this javascript packaging, so
I can focus on finishing the Golang plumbing in Fedora
I suppose this is also a test if a distribution like Fedora/Epel can
still be used to deploy the kind of apps written in 2018, or if it's
condemned to fade and be replaced by other approaches like containers.
Regards,
--
Nicolas Mailhot
5 years, 7 months
Packaging the Javascript layer of Prometheus & Grafana
by Nicolas Mailhot
Hi,
I'm currently investigating the packaging of Prometheus and Grafana in
Fedora/Epel.
Both are cutting-edge high-visibility complex applications written in
Go, that map well to Fedora/Epel historical sysadmin userbase
https://prometheus.io/
https://grafana.com/
I already spent a few months of work working on the Go layer, writing
Golang-to-rpm plumbing, packaging guidelines, packaging and testing
hundreds of spec files. It is finally looking like something that could
end up in the distribution, even though there is still a ton of work to
do plumbing-side to make Go packaging in Fedora simple and convenient.
And I'd like to spend more time making this plumbing a reality.
However, at the same time, the target apps can not be used, since they
include a javascript layer, and I haven't packaged it.
Prometheus provides a bundled copy of the javascript it needs, thus I
supposed it could be packaged as-is, even though that is bad engineering
and totally not what I did for the Go layer.
https://github.com/prometheus/prometheus/tree/master/web/ui/static/vendor
Grafana OTOH has a clean codebase with a build process that uses yarn to
get third-party javascript
https://github.com/grafana/grafana/blob/master/yarn.lock
Therefore, I'm looking for help :
1. either pointers or advice on how to package this javascript cleanly
or
2. ideally, people willing to take over this javascript packaging, so
I can focus on finishing the Golang plumbing in Fedora
I suppose this is also a test if a distribution like Fedora/Epel can
still be used to deploy the kind of apps written in 2018, or if it's
condemned to fade and be replaced by other approaches like containers.
Regards,
--
Nicolas Mailhot
5 years, 7 months
Installing npm tools
by Anatoli Babenia
I need to use `crm` tool from npm, which is not packaged, and using `npm install crx` I couldn't find the binary until I came across this article - http://2ality.com/2016/01/locally-installed-npm-executables.html
It is not recommended way to do this, but for a problem oriented workflow it is still worthy to explain `npm bin`. If there is a way to install such binary utils in isolated environment without hurting system dependencies (Python virtualenv), I would be happy to follow. Making npm-installed packages global is not my goal.
5 years, 8 months
