[HN Gopher] The .meta Directory: Let's Tidy Things Up
___________________________________________________________________
The .meta Directory: Let's Tidy Things Up
Author : geoffeg
Score : 43 points
Date : 2023-06-25 21:08 UTC (1 hours ago)
(HTM) web link (dotmeta.org)
(TXT) w3m dump (dotmeta.org)
| jedberg wrote:
| Back in the day, this is what /etc was for. You'd install
| binaries in /usr or /bin and then NFS mount those from your
| clients. Then all the config was local in /etc (and the programs
| generally respected the idea of either creating a config file in
| /etc on first run or just doing the default thing if it wasn't
| there).
|
| I'm sad that we got away from that standard. It was nice when I
| could just back up /etc and be good to go.
|
| (Of course this is looking with rose colored glasses, we never
| had 100% adherence to the standard, which is how we got to where
| we are).
| PMunch wrote:
| You seem to be thinking of programs, this is talking about
| projects. Various compilers, linkers, CI tools, etc. look in
| the root directory of your project for config files or other
| rules. This proposes to move all those files to `.meta` in
| order to keep the project root directory clean.
| josephg wrote:
| Most of the examples they give - like package.json - are
| specific to the project, not the whole operating system. And
| they are typically checked in to a project's git directory.
|
| /etc stores system configuration (like the local timezone).
| They have a very different purpose.
| rektide wrote:
| It sucks so bad that so much nonsense auxiliary machinery gets
| front row billing.
|
| For a while I was dumping stuff into .config but I eventually
| tired of struggling even more with various tool chains.
| xyst wrote:
| maybe .self is better
| renewiltord wrote:
| In an xkcd standards sense, I propose the folder .stddotfolder
| which can contain a meta dir from hereor a config dir from here
| https://github.com/dot-config/dot-config.github.io
| mickelsen wrote:
| I support this motion.
| notatoad wrote:
| I kinda like the status quo. I like seeing all the tooling
| artifacts at the top level when I open a GitHub repo or
| something, it's nice to see at a glance - like a quick digest of
| what is used to develop that software. And they all are hidden
| automatically in a local file browser, so it's not like it's
| really a mess. And the .prefix means they don't mess up tab
| completion.
|
| It's the ones that _arent_ hidden that are a problem, and if
| they're already obnoxious enough to choose a non-hidden file name
| they're probably not going to support a hidden directory either -
| Dockerfile, Jenkinsfile, and bitbucket-compose.yml, I'm looking
| at you.
| eyelidlessness wrote:
| IMO this should be more aggressive in a few ways, not the least
| being it should invert the fallback logic. It should also include
| some obvious non-config meta-stuff, ie every top level
| Markdown/plain text file save _maybe_ README.
|
| Lastly, I think part of the reason this problem is so annoying to
| warrant it is that lots of tools think they're so special that
| they need to create a new config even when they create
| redundancies with other overlapping config content. I know this
| is a "there are N competing standards" proclamation, but it would
| be nice if same-ecosystem tools were encouraged to collaborate on
| config specs/schemas so a great deal more stuff could be defined
| once, in one format, at one well-known path.
| rco8786 wrote:
| How is this not a very, very, on-the-nose example of "sweeping
| the dust under the rug"
| dstroot wrote:
| This is such a great idea. I kind of hate all the top level
| clutter in my repos and it seems to get worse every year.
| Wonderful suggestion. Whether it's .meta, .config or .etc I don't
| really care.
| kiernanmcgowan wrote:
| Agreed - and if you wanted to be cute about names you'd go with
| .files - dotfiles ;)
| politelemon wrote:
| The name doesn't make sense, those aren't metadata files, they're
| configuration or application.
|
| I guess I'm also not seeing what the exact problem is. The
| project root is crowded, yes, now this suggests making a
| different directory crowded. The messiness is shifted.
| KMnO4 wrote:
| Let's not bikeshed this. The most common use of the meta prefix
| means "about (this category)", eg metadata, but that's not its
| only form.
|
| The original Greek prefix is a preposition that means "with",
| "among", or "beside". Doesn't seem like a stretch that config
| files are a type of metafile.
| joeframbach wrote:
| Why not `.config`?
| mhoad wrote:
| Let's just assume for now that there could be use cases that
| aren't strictly config data.
| rektide wrote:
| 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-...
| XorNot wrote:
| 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?
| eyelidlessness wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-25 23:00 UTC)