[RFH] how to install submodules?

[Alessandro-Barbieri]

Some packages depends on submodules not packaged elsewhere but as a folder in the main project (e.g. language-* from atom)

Here are 3 ways of packaging I've been thinking of:
one ebuild for submodule
pros: no need to change the eclass
cons: ebuild version and tarball version aren't the same, no way to check for updates

let npm manage them
pros: only one ebuild
cons: difficult to put the documentation where it should be, the eclass must take care of package.json and list only the submodules in it before calling npm (currently the eclass clear the dependencies inside package.json). Complex bash/jq scripting needed

manually install the submodules
pros: one ebuild only
cons: Complex bash scripting needed, in the ebuild we need to cd module/folder then run the configure compile install functions

[Alessandro-Barbieri]

I think I'm choosing the first option

[mjsir911]

When I ended up implementing my own js ebuilds, I went with the second option, which has now been added to this repository as node-bundled.eclass

The observed cons of this option are:

• adding a lot of SRC_URI dependencies
• large installations: rollup-bin installs 287 MB of 37780 files
• npm cache add is not equipped for this option, ive been working on PRs to the npm repos to fix this
• sometimes a package-json.lock file needs to be added or updated by the ebuild
• alternative installation sources eg git have yet to be figured out

Now, saying this, I still prefer this option as it is more in-line with how the js ecosystem works.
By far the biggest downside to option one is that package pins are being removed and only one version of a package can be installed at a time because that's all npm supports :(

from https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/

Install it in both places. Seriously, are you that short on disk space? It’s fine, really. They’re tiny JavaScript programs.

But further, the page above talks about using npm link to have globally installed packages and then re-use them.

I think this is a compromise between options 1 & 2. Globally install bulky & stable packages to be reused everywhere, manually npm link them in dependencies so the sources don't get duplicated, and bundle in all the miscellaneous sources. This preserves the deduplication aspect while keeping pinned packages and reducing the number of ebuilds.

This compromise removes or lessens the SRC_URI & installation size problems, while maintaining package pins and simplifying the dynamic ebuild.

This is basically the static vs dynamic linking argument all over again.