On Fri, Sep 18, 2020 at 12:56 PM Troy Dawson <[email protected]> wrote: > > On Fri, Sep 18, 2020 at 8:47 AM Stephen Gallagher <[email protected]> wrote: > > > > On Fri, Sep 18, 2020 at 11:33 AM Troy Dawson <[email protected]> wrote: > > > > > > On Thu, Sep 10, 2020 at 2:27 PM Ben Rosser <[email protected]> wrote: > > > > > > > > On Thu, Sep 3, 2020 at 1:04 PM Troy Dawson <[email protected]> wrote: > > > > > > > > > > On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes <[email protected]> wrote: > > > > > > > > > > > > On 03/09/2020 16:41, Troy Dawson wrote: > > > > > > > > > > > > > Any changes and/or improvements that people think should be made? > > > > > > > > > > > > Well macros for all that boilerplate in the spec is an > > > > > > obvious one. > > > > > > > > > > > > Also making the script fetch the actual version being packaged > > > > > > rather than the latest version would be good. Something like: > > > > > > > > > > > > VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q > > > > > > nodejs-${PACKAGE}.spec)" > > > > > > > > > > > > and then: > > > > > > > > > > > > npm pack ${PACKAGE}@${VERSION} > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > Good point. I guess I had sorta hard coded both the name and the > > > > > version. > > > > > So if they provide a version, use it, and if not, use the latest. > > > > > > > > Hi Troy, > > > > > > > > This looks pretty reasonable to me. (Sorry, I intended to try and work > > > > on something like this myself over the summer but didn't end up having > > > > time. Thanks for working on it!) > > > > > > > > I'd been thinking the script would have one source archive per nodejs > > > > module rather than a single source archive with all the bundled > > > > dependencies, but on second thought that probably would be extremely > > > > unwieldy, so perhaps bundling them together into a tarball is better. > > > > > > > > What are your thoughts on deploying this? Node packages are going to > > > > be broken in Fedora 33, but it's probably way too late to fix that > > > > now, so perhaps there should be a Fedora 34 Change proposal? > > > > > > > > Ben Rosser > > > > > > > > > > I've never done a change proposal, so I'm not sure of everything it > > > would involve. > > > Do we say something to the effect of "All non-needed nodejs libraries > > > are to be removed, and those that are needed will bundle their > > > dependencies in this way?" > > > > > > We would then have to define "needed" libraries. > > > I would think of these as the initial libraries other packages require. > > > An example would be nodejs-showdown. R-shiny requires nodejs-showdown > > > to build and run. > > > So nodejs-showdown would be a needed nodejs-library. But we could > > > bundle all of its runtime and testing dependencies, so it wouldn't > > > drag in any extra nodejs libraries. > > > > > > If we are going along that route, I think saying something similar for > > > nodejs binaries would be appropriate. Packages like coffee-script, > > > uglify-js, and other packages like those. > > > Perhaps not as strong as with libraries, something like > > > "Nodejs binaries should bundle their nodejs runtime and testing > > > dependencies whenever possible. If it is not possible, then those > > > nodejs dependencies should be treated as needed nodejs libraries." > > > > > > > Frankly, I think we should probably get out of the business of > > shipping library NPMs entirely. Upstream's stance on global vs. local > > NPM installations is this [1]: > > > > """ > > Just like how global variables are kind of gross, but also necessary > > in some cases, global packages are important, but best avoided if not > > needed. > > > > In general, the rule of thumb is: > > > > * If you’re installing something that you want to use in your program, > > using require('whatever'), then install it locally, at the root of > > your project. > > * If you’re installing something that you want to use in your shell, > > on the command line or something, install it globally, so that its > > binaries end up in your PATH environment variable. > > """ > > > > So, as a shorthand, I think Fedora should only package: > > > > 1) The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > 2) Packages that provide binaries that users would want to use in their > > shell. > > > > I'm not sure when bundling their dependencies would be impossible. Can > > you provide an example? The whole ecosystem is designed around > > bundling as the preferred approach. > > > > > > [1] https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/ > > I can't provide an example of when bundling would be impossible. I > just assumed there would be one. > Part of me thinks this will be alot of work, and another part of me > thinks it will be less work than what I was proposing above. > > I like your proposal over mine. It's more clear, and clean. And > after the initial set of work, the packaging workload drops. > > Does anyone have any major objections before I look at how to do a > Fedora change proposal? > > Troy >
At least for the short term, I'd suggest adding (3): compiled/binary nodejs modules; there aren't very many of these in the ecosystem anyway, as I understand it (there certainly aren't very many in Fedora) so I don't think it would be too much work to package them separately. Otherwise, this sounds good to me! Ben Rosser _______________________________________________ nodejs mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
