FreeBSD support

[tsgan]

Hi,

We have created necessary changes to support nvm in FreeBSD.
Basically it uses FreeBSD pkg system to install node and npm versions from packages to its necessary places.

The change is at:

master...ateamsystems:master

Please take a look at only nvm.sh related changes and let us know how it looks like.
If it is generally OK then we can clean it up and make pull request.
Please let us know if you have any questions.

thanks a lot,
Ganbold

[ljharb]

Absolutely I do not want anything installing node/npm from anywhere but the official site - distro packages are unofficial, and shouldn't be used to install node. I'm open to things that improve FreeBSD support, but using pkg isn't the right path.

Separately, why change ∞ to ????

[ateam-adam]

ljharb we use pkg because node does not compile cleanly without patches under FreeBSD, especially for past versions, last i had checked which is part of why we use pkg. I feel like the amount of work to back port every major.minor version is not going to happen for FreeBSD .. or it would have already.

[ljharb]

That's quite possibly true. I think that the direction for FreeBSD users here is:

1. get node to start supporting FreeBSD from any point onwards, and nvm will support that too
2. explore a way to hook into nvm and provide the patches for older versions

If node doesn't support FreeBSD, most of the ecosystem likely won't either.

[ateam-adam]

NPM and it's modules for the most part work out of the box with no problem. So the issue is really just node itself. Getting node to support FreeBSD better is a task which is ... something else entirely.

We debated long and hard how to best treat this. We wanted to give you a chance to review this before we simply forked this entirely from NVM and made a "FreeBSD NVM".

Is there anything we could do to avoid this (UTF conversions aside :P) ?

[tsgan]

∞ was changed to ??? due to editor I was using, I can fix that.

But overall there are node and npm versions of official FreeBSD packages exists already so it is easier to install them using pkg system.

[ljharb]

@ateam-adam I think perhaps a better approach is actually hosting archives that are FreeBSD-compatible on a site that mirrors https://nodejs.org/dist - and then setting the NVM_NODEJS_ORG_MIRROR environment variable to point to your mirror. Then you won't require any changes in nvm at all.

[ateam-adam]

Not sure if this is what you mean but with FreeBSD the way it's handled either for a port (compiled by user locally) or a pkg (built by compiling the port on a port building machine) is the port grabs the dist file, from nodejs.org then applies the FreeBSD patches. So there is no "free standing" archive of the resulting code -- except as a package after it's compiled. The port itself just references a software's download and contains patches to apply (I'm being simplistic here).

So if your asking if there is a node-that-works-on-freebsd.tar.gz somewhere there isn't. One could be made but this brings it 100% out of line with all the existing pipelines. We wanted to capitalize on the effort already made by the FreeBSD node portmaintainers. Which, I agree ... there shouldn't need to be 91 lines of patches to make, for example 0.12, compile properly. But again, there it is.

When there is a security or other update since this is tied to ports/pkgs it is addressed as part of the pipeline, we're not having to cut a tar.gz file or 'keep up'. The flip side is, you don't have NVM's range on Linux which is "every version ever". This was the trade off. For our use, the massive (and continuous effort) to support that is not worth it.

Let me know if that makes sense.

[ljharb]

@ateam-adam another possibility, however, is that after #1204 lands, you could, on-the-fly, generate that .tar.gz, put it in the right place, and then initiate the nvm commands. Would that work?

[ljharb]

Actually now that I think about it, that wouldn't work, because the checksums would still not match :-/

[ljharb]

I'm very open to exploring how to make this work - but putting pkg inside nvm.sh doesn't seem to be the right solution to me.

Could you use pkg yourself to install the desired version X of node to nvm_version_path "$(nvm_version X)", and then let nvm take over after that? If that works, I'd be happy to add that as a top-level API (instead of using nvm internals)

[ateam-adam]

I was thinking that might be cool but I think there would be other issues we'd run into. The local user would need the entire ports tree on their machine and it would need to be kept up to date -- something that pkg has thankfully eliminated unless you absolutely want to deal with it. It's not a show stopper but there would be additional complexity in 'cooking' that stuff on the fly, and that's just off the top of my head.

There is also dependencies which pkg handles, which again not a show stopper, but just a potential pandora's box.

And yeah, checksums would no longer match ..

[ateam-adam]

That is what this does unless I mistake your meaning. At no point does node get installed "on the system", all the pkg commands are targeted at /tmp (@tsgan can provide more detail here) then moved into place in nvm_version_path basically. You end up having to duplicate some deps but it's clean and it works, and it is not fragile (really the big thing for me).

And those duplicated deps are duplicated inside the nvm_version_path for a specific version. So it maintains FreeBSD's dep tree for each version.

[ljharb]

Right - I guess I'm asking if you can pass that path directly into pkg outside of nvm - and then you could just override nvm install (potentially with a PR that makes the command configurable)

[ateam-adam]

I will leave this up to @tsgan to answer :)

P.S. Very much appreciate you working to try to find a solution here 👍