You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something like $N_NODE_MIRROR is useful to set in an environment that requires it as a default. It would be nice to be able to do the same with some $N_ARCH.
Not having this is not only ugly (I use an env var for one setting, and a flag for the other), but less convenient since I cannot set a default as I can with the mirror.
In my case, I have an old server that uses the unofficial-builds repo to get the x64-glibc-217 builds. The thing is that n has very simple logic for getting the architecture, so adding stuff that inspects the glibc version would probably be prohibitively complicate and even more impractical since the architecture can depend on the mirror that is used.
(I'm willing to do a PR if this sounds like a good idea.)
The text was updated successfully, but these errors were encountered:
Supporting N_ARCH would be in line with the mirror support and reasonable. I am open to looking at a PR for that (and willing to do it myself too). I think the code change might be a one liner, but I would also like N_ARCH listed in n doctor if set, like N_PREFIX et al.
Done in #832. As I said there, the big chunk is just avoiding the uname dance if it's not needed, and it would be better to do that in a separate PR if you prefer that.
Something like
$N_NODE_MIRROR
is useful to set in an environment that requires it as a default. It would be nice to be able to do the same with some$N_ARCH
.Not having this is not only ugly (I use an env var for one setting, and a flag for the other), but less convenient since I cannot set a default as I can with the mirror.
In my case, I have an old server that uses the unofficial-builds repo to get the
x64-glibc-217
builds. The thing is thatn
has very simple logic for getting the architecture, so adding stuff that inspects the glibc version would probably be prohibitively complicate and even more impractical since the architecture can depend on the mirror that is used.(I'm willing to do a PR if this sounds like a good idea.)
The text was updated successfully, but these errors were encountered: