5 ms·

Let’s just assume for now that there could be use cases that aren’t strictly config data.

by mhoad 3y ago

rektide 3y ago
I do think .etc would be a pleasantly smart way to blend with the rest of the world as it exists. This case isn't covered by XDG, but there's a path here we probably could & should adapt, that suggests itself. And this forges off in a new direction. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...
- XorNot 3y ago
  We already have the ~/.local (standard? convention?) which simply mimics the filesystem root with bin,etc,include etc. If we're tossing this into random subfolders, I'm not sure why we wouldn't keep that going?
  - saghm 3y ago
    > ~/.local (standard? convention?) which simply mimics the filesystem root with bin,etc,include etc. That's not the filesystem root, is it? From what I can tell, ~/.local mimics `/usr`; it has bin and include, yes, but also `share`, and no `/etc` that I'm aware of. `/` does have `bin`, but I don't think I've ever seen `include` there on a system before.
    - XorNot 3y ago
      `/usr` can have `/etc` - and my current .local has an `etc` directory directory in it (apparently used by jupyter).
      - saghm 3y ago
        Fair enough, but I think that's even more evidence that `.local` doesn't actually mimic the filesystem root, but `/usr`
  - rektide 3y ago
    I like the idea of a .local! It's a little weird because presumably repos shouldn't just be a .local folder. We'd still be excepting the actual source from this. Maybe we just use a FileSystem Heirarchy pattern for repos? Many projects already have source in src/. Move all the build config stuff into a etc/ in the project, no .anything/?
TrueDuality 3y ago
The XDG standard covers most of these as well. Cached data that is safe to delete? There is a directory for that. Runtime data that needs to live as long as the instance of the app? Directory for that. External data your app might rely on but contains no user data? Directory for that. It's very flexible and widely accepted. It's just not accepted _enough_ to be annoying.

Let’s just assume for now that there could be use cases that aren’t strictly config data.

by mhoad 3y ago

Let’s just assume for now that there could be use cases that aren’t strictly config data.

I do think .etc would be a pleasantly smart way to blend with the rest of the world as it exists. This case isn't covered by XDG, but there's a path here we probably could & should adapt, that suggests itself. And this forges off in a new direction. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...

XorNot 3y ago
We already have the ~/.local (standard? convention?) which simply mimics the filesystem root with bin,etc,include etc. If we're tossing this into random subfolders, I'm not sure why we wouldn't keep that going?
- saghm 3y ago
  > ~/.local (standard? convention?) which simply mimics the filesystem root with bin,etc,include etc. That's not the filesystem root, is it? From what I can tell, ~/.local mimics `/usr`; it has bin and include, yes, but also `share`, and no `/etc` that I'm aware of. `/` does have `bin`, but I don't think I've ever seen `include` there on a system before.
  - XorNot 3y ago
    `/usr` can have `/etc` - and my current .local has an `etc` directory directory in it (apparently used by jupyter).
    - saghm 3y ago
      Fair enough, but I think that's even more evidence that `.local` doesn't actually mimic the filesystem root, but `/usr`
- rektide 3y ago
  I like the idea of a .local! It's a little weird because presumably repos shouldn't just be a .local folder. We'd still be excepting the actual source from this. Maybe we just use a FileSystem Heirarchy pattern for repos? Many projects already have source in src/. Move all the build config stuff into a etc/ in the project, no .anything/?

TrueDuality 3y ago

The XDG standard covers most of these as well. Cached data that is safe to delete? There is a directory for that. Runtime data that needs to live as long as the instance of the app? Directory for that. External data your app might rely on but contains no user data? Directory for that. It's very flexible and widely accepted. It's just not accepted _enough_ to be annoying.