I should have changed the name of the feature. It is not XDG_DATA_HOME, but the standard data locations for each OS. ~/Library/Application Support/fnm seems to be the standard per https://docs.rs/dirs/latest/dirs/fn.data_dir.html

If you think this is the wrong choice, please reopen.

Thanks for the input 🙏

In macOS environment, XDG_DATA_HOME does not exist, so there is no problem to use the path under Library as the default fnm folder. And it will affect almost no one except developers who explicitly want to use XDG_DATA_HOME on macOS.

However, if the XDG_DATA_HOME environment variable exists, my recommendation is to uniformly honor this.

Because some developers work in cross-platform environments, they may set this environment variable themselves and potentially use unified dotfiles to ensure consistency across environments. They expect all data files to be located under ~/.local for easy management.

I hope you understand this usage requirement and reduce fragmentation of fnm behavior, thanks.

It seems that I cannot reopen the issue on my own.

It seems that I cannot reopen the issue on my own.

didn't know that. sorry.

I understand your frustration, but I also agree with dirs-dev/directories-rs#47 (comment)

that being said, maybe it's time to have a crate::dirs module that works with these defaults? I dunno. I'm opening anyway :)

it's worth to mention that I do not like to use ~/Library/ stuff in a CLI too. I share the sentiment.

Thank you for pointing out the related discussion.

I respect your choice and understand your intentions.

I as a developer respect the default folder location of the platform and use it, but also respect the user.
As a user, I own my environment, not the landlord.

BTW, I'm also using macOS 12.1 but made changes to the file path and do not use the default location. No wonder I didn't notice the recently mentioned TMPDIR problem. 🤣🤣🤣

@Schniz This issue seems to break npx because node versions get installed into Application Support, which has a space in the name.

Using default install through homebrew.

$ npx forever ./foo
node:events:371
      throw er; // Unhandled 'error' event
      ^

Error: spawn /Users/user/Library/Application EACCES
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:288:12)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -13,
  code: 'EACCES',
  syscall: 'spawn /Users/user/Library/Application',
  path: '/Users/user/Library/Application',
  spawnargs: [
    'Support/fnm/node-versions/v16.9.0/installation/bin/node',
    '/Users/user/baz/bar/foo'
  ]
}

@MarttiR

This issue is about XDG_DATA_HOME not being respected, not related to the recent default installation location changes. Perhaps you are looking for a different PR or issue. ( PR number 416)

Sorry for the noise, then – just switched over from nvm today, so I'm not familiar with recent PR activity. Also, this was the only issue of two found in the search that seemed relevant to the problems I was experiencing.

In any case, installing manually with --install-dir $HOME/.fnm --force-no-brew fixed my issue above.

Thanks for sharing the solution. Maybe it will help others.

I don't like the idea of installing command line programs by default to a path location like Application Support with spaces in it.

Because you don't know when something weird will happen.
This is a problem that needs to be addressed seriously.

I will try to take a look at that. I agree that Application Data is not a good idea. That still sounds odd that it fails though. Since we introduced a directories module we can do the same with the fnm dir.

Do you have a suggestion on how you think it should work? 🙏

data_dir():

• $XDG_DATA_HOME
• dirs::data_local_dir

fnm dir:

• $XDG_DATA_HOME / fnm
• is darwin?
  • ~/Library/fnm
  • I don't like polluting here either, I don't like it at all. But you know, in the end, this is the only place that fits.
  • There are also other projects, such as pnpm installed here.
  • Otherwise all that remains is ~/.fnm
• dirs::data_local_dir / fnm

For fnm default location, or keep it as is, let the users change the location by themselves.
As you can't take care of all cases.
These are some of my thoughts.

@Schniz Are you interested in a PR with support for XDG conventions on macOS?

About space in the path (Application Support): currently, all npm's help pages are not readable, ie:

vv@my-precious ~/work/own/reard/new-reard/api $ npm help dedupe
[
  'man',
  [
    '/Users/vv/Library/Application Support/fnm/node-versions/v18.16.0/installation/lib/node_modules/npm/man/man1/npm-dedupe.1'
  ]
]
/usr/bin/man: line 413: cd: /Users/vv/Library/Application: No such file or directory
npm ERR! help process exited with code: 1

npm ERR! A complete log of this run can be found in: /Users/vv/.npm/_logs/2023-05-08T17_27_25_690Z-debug-0.log
vv@my-precious ~/work/own/reard/new-reard/api $ 

This happens due to a bug in /usr/bin/man (shell script), which can't handle spaces in the path. I submitted a bug to Apple, but not sure how many time they will need to actually fix it

I've created #959 to address this issue.

I've chosen a different approach than @page-down suggested. I don't think it's a good idea to half-ass XDG conventions because the users who're not familiar with it might be confused as to why fnm broke after they set or unset XDG variables. IMO, setting XDG vars to the default value or not setting them shouldn't change a program's behavior. So the current location is only used as a fallback. (If any of ~/.local/share/fnm or ~/.fnm exist, then ~/Library/Application Support will be ignored).

In addition, fnm will now also respect XDG_RUNTIME_DIR/XDG_STATE_HOME/XDG_CACHE_HOME for multishell_storage. This might be a slightly breaking change which should be solved by restarting the shell after upgrading.