Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: architecture env var #830

Open
elibarzilay opened this issue Feb 6, 2025 · 2 comments
Open

Feature request: architecture env var #830

elibarzilay opened this issue Feb 6, 2025 · 2 comments
Labels
pending release Merged into a branch for a future release, but not released yet

Comments

@elibarzilay
Copy link
Contributor

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.)

@shadowspawn
Copy link
Collaborator

Thanks for the use case.

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.

@elibarzilay
Copy link
Contributor Author

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.

@shadowspawn shadowspawn added the pending release Merged into a branch for a future release, but not released yet label Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending release Merged into a branch for a future release, but not released yet
Projects
None yet
Development

No branches or pull requests

2 participants