17 ms·

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 https://co

by orlp 1y ago

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 https://codeberg.org/dirs/dirs-rs/issues/64. It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windows)] fn get_config_base_dir() -> Result<PathBuf> { use known_folders::{KnownFolder, get_known_folder_path}; get_known_folder_path(KnownFolder::RoamingAppData).context("unable to get config dir") } #[cfg(not(windows))] fn get_config_base_dir() -> Result<PathBuf> { let base_dirs = xdg::BaseDirectories::new().context("unable to get config dir")?; Ok(base_dirs.get_config_home()) }

CGamesPlay 1y ago
I think there should be two crates in rust-land. The answer by @soc makes sense for apps, as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".
- adastra22 1y ago
  A CLI app is an app.
  - CGamesPlay 1y ago
    Not in Apple's nomenclature, it isn't. An App specifically refers to a folder named ".app" with an info.plist and a binary inside of it. It can also contain a bunch of other metadata and application data. To apple, a "CLI app" as you call it is just the binary (a single file). But the real distinction is that the "Apple App" manages its preferences in-app. The "CLI app" does not, the user is expected to manage this configuration themselves.
    - adastra22 1y ago
      What you are talking about is an application bundle.
- JoshTriplett 1y ago
  It sounds like https://docs.rs/etcetera/0.3.2/etcetera/index.html https://docs.rs/etcetera/0.3.2/etcetera/index.html provides sufficient flexibility for apps that want this.
- systoll 1y ago
  What does making a different choice for GUI and CLI apps achieve, other than making it impossible to ever have a single coherent place to look/synchronise/etc? XDG's spec doesn't make such a distinction, so you’re advocating for a new competing standard. I don't think Apple’s documentation intends to cover command line programs, but… in the absence of any concrete rule, putting your files where most programs on the system do is a reasonable choice, and that place will never be ~/.config/ on macOS. Apps like homebrew that default to the library but support XDG_CONFIG_HOME if explicitly set, are a decent compromise, though.
quotemstr 1y ago
> they refuse to see it this way That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to lift even the lightest of fingers for the common good. Consider https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ The XDG specification has been around for 22 years. It has real benefits for users. It's trivial to implement. Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. The only thing that works is to sandbox applications at tightly as possible and direct all their access to the external world through narrow interfaces that do their best to limit shenanigans.
- happymellon 1y ago
  It's a shame that MacOS doesn't have an equivalent for Boxxy.
- Gigachad 1y ago
  How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.
- eklavya 1y ago
  I have absolutely no opinion on "common good" or "standard" here. I wholeheartedly agree about the containers part though, just have everything within a folder in a container somewhere so I don't have to keep googling where X stores Y and still failing half the time.
- bayindirh 1y ago
  > That's why the long-term future of app development is containers. That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach. > I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft... > I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here. > The only thing that works is to sandbox applications at tightly as possible Don't be so defeatist, though.
joshka 1y ago
From my previous recollection, there's an issue for this in just about every rust crate that handles these dirs. The right way to fix this is fix the spec, then make the libs adhere to the spec.
- Null-Set 1y ago
  How would you fix the spec? Add a line explicitly stating the /Library/Application Support dir is only for applications with a bundle ID, instead of just implying it?
- re 1y ago
  For clarity, is this what you're referring to as "the spec"? https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html https://developer.apple.com/library/archive/documentation/Fi...
  - deleted 1y ago
    [deleted]
  - joshka 1y ago
    No the xdg base directories spec. If you want to be able to opt in to dry on a system which doesn’t canonically use xdg vars, then you need some config.
    - SAI_Peregrinus 1y ago
      XDG is cross-distribution for Linux, but it's not cross-platform. MacOS doesn't use XDG.
      - joshka 1y ago
        That’s my point. MacOS doesn’t use it, but many expect it to do so, so make this explicitly opt in so that a user’s preference is respected over the canonical configuration. To do that the best place to define the setting is in the spec.
bowsamic 1y ago
Why is that soc guy so angry and rude about it?
- orlp 1y ago
  I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.
  - GoblinSlayer 1y ago
    The library addresses your use case: provides location to store configs. You're asking for your personal feature.
- dclowd9901 1y ago
  [flagged]
  - mtndew4brkfst 1y ago
    It's unkind to publicly speculate on this in this particular way, IMO.
    - dclowd9901 1y ago
      Kindness is reciprocal, IMO. But I will concede speculation is unproductive.
- x3n0ph3n3 1y ago
  Certainly doesn't make me want to become a Rust contributors.
  - dagmx 1y ago
    dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.
forrestthewoods 1y ago
> I'm not writing an app, just a CLI tool but CLI tools are applications
- goranmoomin 1y ago
  No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth. CLI tools, including ones that Apple ships or makes, are not apps on macOS. I’m sorry, this is my pet peeve as well and it’s very frustrating to see this ‘CLI tools are apps’ argument from developers who are not familiar with the Apple guidelines, and then argue about on an ideological basis.
- padjo 1y ago
  That is covered in the article. An “App” on Mac is a specific thing with certain characteristics that CLI tools don’t have.
kstenerud 1y ago
Sounds like it's time to make a fork of dirs-rs that actually follows the rules. Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.
- franga2000 1y ago
  Where do I store my files is never a simple replacement. At the very least you need to write a migration routine and maintain it for a very long time.
  - Hendrikto 1y ago
    This has been a solved problem forever. It is very simple, very easy, very short, extremely maintainable code. When writing the files, check the old location first, fall back to the new one. When reading, check check the new location first, fall back to the old one. The app does not need to migrate anything. Using the algorithm described above, new installations will automatically use the new paths, old installations will continue using the old paths, but can optionally be migrated at the user’s convenience.
    - franga2000 1y ago
      But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path(), copy the files, delete the old dir, them and then read from the new one. What if it's a symlink? What if copying fails mid-way? Does the library or the program handle all of this? Can you even compile against both libraries if one is a fork of the other (namespace issues)?
      - BenjiWiebe 1y ago
        The app doesn't migrate the files, so no worrying about copying. Don't bother even checking if it's a symlink. A symlink is a file. Just open it and read it.
soni96pl 1y ago
From the same person: https://soc.me/standards/defending-home https://soc.me/standards/defending-home I'm aware it mentions Linux specifically, but this is golden: > From this point on, the number of dot-files and dot-directories can only shrink as the remaining applications get fixed and start conforming to the XDG base directory spec, while no new dot-files and dot-directories can be added to your home directory. As is original reasoning for not using ~/.config from https://github.com/dirs-dev/directories-rs/issues/62#issuecomment-586716033 https://github.com/dirs-dev/directories-rs/issues/62#issueco... > As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working. I get the feel he just does not like macOS?
- delta_p_delta_x 1y ago
  That hyperlink redirects back to HN. There's JS on the site that redirects 'undesirables' like HN, formerly Reddit, and lobste.rs.
tyilo 1y ago
It seems like `etcetera` has better defaults: https://docs.rs/etcetera/latest/etcetera/#native-strategy https://docs.rs/etcetera/latest/etcetera/#native-strategy > `choose_base_strategy()` and `choose_app_strategy()` will use the XDG strategy on Linux & macOS, and the Windows strategy on Windows. This is used by most CLI tools & some GUI tools on each platform.
xyst 1y ago
dirs maintainer is bit unhinge, maybe the high usage of crate has gotten to their head. If I ever have time, I would love to fork this repository, patch it to support XDG_*, and actively work to advertise it across the rust ecosystem. If user wants to use different location on file system to store configuration files, then let them. Stop trying to dictate what users want.
- rblatz 1y ago
  The spec from Apple could be clearer, you have to read the tea leaves and both sides have enough ammo to argue for their interpretation. But as someone who doesn’t care either way where these are stored I think that makes me a bit more objective than people who strongly have an opinion that they are looking to justify. I think the Application support people have a stronger argument. Nowhere does it say store it in ~/.config for CLI tools. Also it seems weird to store user preferences in two different locations based on if it’s a CLI app or a GUI app. What if you have both interfaces? I’m not saying that Application Support is the better solution, and if people feel that there should be a distinction between CLI apps and GUI apps they should push for Apple to update their standards. Repeatedly harassing an open source maintainer to relitigate an issue they’ve already decided on is counter productive and a waste of the maintainer’s time. I would be frustrated if I was him as well.
GoblinSlayer 1y ago
The maintainer's advice is correct, on mac you should store configs and other stuff in Library/Application Support, that's the mac convention to use on mac, just like xdg is linux convention to use on linux.

by orlp 1y ago

CGamesPlay 1y ago

I think there should be two crates in rust-land. The answer by @soc makes sense for apps, as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".

adastra22 1y ago
A CLI app is an app.
- CGamesPlay 1y ago
  Not in Apple's nomenclature, it isn't. An App specifically refers to a folder named ".app" with an info.plist and a binary inside of it. It can also contain a bunch of other metadata and application data. To apple, a "CLI app" as you call it is just the binary (a single file). But the real distinction is that the "Apple App" manages its preferences in-app. The "CLI app" does not, the user is expected to manage this configuration themselves.
  - adastra22 1y ago
    What you are talking about is an application bundle.
JoshTriplett 1y ago
It sounds like https://docs.rs/etcetera/0.3.2/etcetera/index.html https://docs.rs/etcetera/0.3.2/etcetera/index.html provides sufficient flexibility for apps that want this.
systoll 1y ago
What does making a different choice for GUI and CLI apps achieve, other than making it impossible to ever have a single coherent place to look/synchronise/etc? XDG's spec doesn't make such a distinction, so you’re advocating for a new competing standard. I don't think Apple’s documentation intends to cover command line programs, but… in the absence of any concrete rule, putting your files where most programs on the system do is a reasonable choice, and that place will never be ~/.config/ on macOS. Apps like homebrew that default to the library but support XDG_CONFIG_HOME if explicitly set, are a decent compromise, though.

quotemstr 1y ago

> they refuse to see it this way That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to lift even the lightest of fingers for the common good. Consider https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ The XDG specification has been around for 22 years. It has real benefits for users. It's trivial to implement. Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. The only thing that works is to sandbox applications at tightly as possible and direct all their access to the external world through narrow interfaces that do their best to limit shenanigans.

happymellon 1y ago
It's a shame that MacOS doesn't have an equivalent for Boxxy.
Gigachad 1y ago
How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.
eklavya 1y ago
I have absolutely no opinion on "common good" or "standard" here. I wholeheartedly agree about the containers part though, just have everything within a folder in a container somewhere so I don't have to keep googling where X stores Y and still failing half the time.
bayindirh 1y ago
> That's why the long-term future of app development is containers. That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach. > I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME. I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft... > I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here. > The only thing that works is to sandbox applications at tightly as possible Don't be so defeatist, though.

joshka 1y ago

From my previous recollection, there's an issue for this in just about every rust crate that handles these dirs. The right way to fix this is fix the spec, then make the libs adhere to the spec.

Null-Set 1y ago
How would you fix the spec? Add a line explicitly stating the /Library/Application Support dir is only for applications with a bundle ID, instead of just implying it?
re 1y ago
For clarity, is this what you're referring to as "the spec"? https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html https://developer.apple.com/library/archive/documentation/Fi...
- deleted 1y ago
  [deleted]
- joshka 1y ago
  No the xdg base directories spec. If you want to be able to opt in to dry on a system which doesn’t canonically use xdg vars, then you need some config.
  - SAI_Peregrinus 1y ago
    XDG is cross-distribution for Linux, but it's not cross-platform. MacOS doesn't use XDG.
    - joshka 1y ago
      That’s my point. MacOS doesn’t use it, but many expect it to do so, so make this explicitly opt in so that a user’s preference is respected over the canonical configuration. To do that the best place to define the setting is in the spec.

bowsamic 1y ago

Why is that soc guy so angry and rude about it?

orlp 1y ago
I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.
- GoblinSlayer 1y ago
  The library addresses your use case: provides location to store configs. You're asking for your personal feature.
dclowd9901 1y ago
[flagged]
- mtndew4brkfst 1y ago
  It's unkind to publicly speculate on this in this particular way, IMO.
  - dclowd9901 1y ago
    Kindness is reciprocal, IMO. But I will concede speculation is unproductive.
x3n0ph3n3 1y ago
Certainly doesn't make me want to become a Rust contributors.
- dagmx 1y ago
  dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.

forrestthewoods 1y ago

> I'm not writing an app, just a CLI tool but CLI tools are applications

goranmoomin 1y ago
No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth. CLI tools, including ones that Apple ships or makes, are not apps on macOS. I’m sorry, this is my pet peeve as well and it’s very frustrating to see this ‘CLI tools are apps’ argument from developers who are not familiar with the Apple guidelines, and then argue about on an ideological basis.
padjo 1y ago
That is covered in the article. An “App” on Mac is a specific thing with certain characteristics that CLI tools don’t have.

kstenerud 1y ago

Sounds like it's time to make a fork of dirs-rs that actually follows the rules. Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.

franga2000 1y ago
Where do I store my files is never a simple replacement. At the very least you need to write a migration routine and maintain it for a very long time.
- Hendrikto 1y ago
  This has been a solved problem forever. It is very simple, very easy, very short, extremely maintainable code. When writing the files, check the old location first, fall back to the new one. When reading, check check the new location first, fall back to the old one. The app does not need to migrate anything. Using the algorithm described above, new installations will automatically use the new paths, old installations will continue using the old paths, but can optionally be migrated at the user’s convenience.
  - franga2000 1y ago
    But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path(), copy the files, delete the old dir, them and then read from the new one. What if it's a symlink? What if copying fails mid-way? Does the library or the program handle all of this? Can you even compile against both libraries if one is a fork of the other (namespace issues)?
    - BenjiWiebe 1y ago
      The app doesn't migrate the files, so no worrying about copying. Don't bother even checking if it's a symlink. A symlink is a file. Just open it and read it.

soni96pl 1y ago

From the same person: https://soc.me/standards/defending-home https://soc.me/standards/defending-home I'm aware it mentions Linux specifically, but this is golden: > From this point on, the number of dot-files and dot-directories can only shrink as the remaining applications get fixed and start conforming to the XDG base directory spec, while no new dot-files and dot-directories can be added to your home directory. As is original reasoning for not using ~/.config from https://github.com/dirs-dev/directories-rs/issues/62#issuecomment-586716033 https://github.com/dirs-dev/directories-rs/issues/62#issueco... > As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working. I get the feel he just does not like macOS?

delta_p_delta_x 1y ago
That hyperlink redirects back to HN. There's JS on the site that redirects 'undesirables' like HN, formerly Reddit, and lobste.rs.

tyilo 1y ago

It seems like `etcetera` has better defaults: https://docs.rs/etcetera/latest/etcetera/#native-strategy https://docs.rs/etcetera/latest/etcetera/#native-strategy > `choose_base_strategy()` and `choose_app_strategy()` will use the XDG strategy on Linux & macOS, and the Windows strategy on Windows. This is used by most CLI tools & some GUI tools on each platform.

xyst 1y ago

dirs maintainer is bit unhinge, maybe the high usage of crate has gotten to their head. If I ever have time, I would love to fork this repository, patch it to support XDG_*, and actively work to advertise it across the rust ecosystem. If user wants to use different location on file system to store configuration files, then let them. Stop trying to dictate what users want.

rblatz 1y ago
The spec from Apple could be clearer, you have to read the tea leaves and both sides have enough ammo to argue for their interpretation. But as someone who doesn’t care either way where these are stored I think that makes me a bit more objective than people who strongly have an opinion that they are looking to justify. I think the Application support people have a stronger argument. Nowhere does it say store it in ~/.config for CLI tools. Also it seems weird to store user preferences in two different locations based on if it’s a CLI app or a GUI app. What if you have both interfaces? I’m not saying that Application Support is the better solution, and if people feel that there should be a distinction between CLI apps and GUI apps they should push for Apple to update their standards. Repeatedly harassing an open source maintainer to relitigate an issue they’ve already decided on is counter productive and a waste of the maintainer’s time. I would be frustrated if I was him as well.

GoblinSlayer 1y ago

The maintainer's advice is correct, on mac you should store configs and other stuff in Library/Application Support, that's the mac convention to use on mac, just like xdg is linux convention to use on linux.