7 ms·

Why not `.config`?

by joeframbach 3y ago

Why not `.config`?

codegeek 3y ago
How about .dotfiles ?
mhoad 3y ago
Let’s just assume for now that there could be use cases that aren’t strictly config data.
- 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.
eyelidlessness 3y ago
At least a couple of them are unambiguously programs (despite being defined in config formats). And many of the others are configs which allow program formats, which could hypothetically do arbitrary program things as well. There are other top level files which I’d want to include if I were the one designing this, many of which are just text/reference, all of which are inherently meta content relative to their containing project. It may well even be worth nesting sub-category directories below .meta, eg .meta/config or even .meta/config/{checks,env,…}. I’m sure some would consider any/all of this overkill, but the current status quo of top-level junk is certainly no better than a tree with well defined and well named branches.
Noumenon72 3y ago
".config" seems like such a natural name for it that I assumed it must be taken by some other program so they couldn't use it. I would expect a ".meta" folder to hold things like release history, a graph of the number of files in the project over time, links to external design documents, and other facts "about" the project. Not config files used by the project.
- TrueDuality 3y ago
  It kind of is... There is a formal standard that everyone ignores called XDG which defines the ".config" directory along with a few other handy common ones.
  - mftrhu 3y ago
    The XDG base directory specification defines a .config directory for user-specific configuration files (e.g. tmux.conf, i3's config file, a global gitignore file). This proposed standard would be for project-specific configuration files (e.g. a project-local .gitignore, .dir-locals.el, .mypy.ini).

Why not `.config`?

codegeek 3y ago

How about .dotfiles ?

mhoad 3y ago

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

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.

eyelidlessness 3y ago

At least a couple of them are unambiguously programs (despite being defined in config formats). And many of the others are configs which allow program formats, which could hypothetically do arbitrary program things as well. There are other top level files which I’d want to include if I were the one designing this, many of which are just text/reference, all of which are inherently meta content relative to their containing project. It may well even be worth nesting sub-category directories below .meta, eg .meta/config or even .meta/config/{checks,env,…}. I’m sure some would consider any/all of this overkill, but the current status quo of top-level junk is certainly no better than a tree with well defined and well named branches.

Noumenon72 3y ago

".config" seems like such a natural name for it that I assumed it must be taken by some other program so they couldn't use it. I would expect a ".meta" folder to hold things like release history, a graph of the number of files in the project over time, links to external design documents, and other facts "about" the project. Not config files used by the project.

TrueDuality 3y ago
It kind of is... There is a formal standard that everyone ignores called XDG which defines the ".config" directory along with a few other handy common ones.
- mftrhu 3y ago
  The XDG base directory specification defines a .config directory for user-specific configuration files (e.g. tmux.conf, i3's config file, a global gitignore file). This proposed standard would be for project-specific configuration files (e.g. a project-local .gitignore, .dir-locals.el, .mypy.ini).