20 ms·
The .meta directory: let's tidy things up
- paulddraper 3y agoWhy not tools/ ?
- joeframbach 3y agoWhy not `.config`?
- codegeek 3y agoHow about .dotfiles ?
- mhoad 3y agoLet’s just assume for now that there could be use cases that aren’t strictly config data.
- rektide 3y agoI 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 agoWe 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.
- rektide 3y agoI 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 agoThe 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 agoAt 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 agoIt 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 agoThe 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).
- rektide 3y agoIt 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.
- dstroot 3y agoThis 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 3y agoAgreed - and if you wanted to be cute about names you'd go with .files - dotfiles ;)
- eyelidlessness 3y agoIMO 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.
- cxr 3y ago> It should also include some obvious non-config meta-stuff, ie every top level Markdown/plain text file save maybe README. The problem you're trying to solve with this is just related to the fact that README starts with R. In the past, I've been an advocate for breaking with tradition and naming your README "ABOUT" instead. > 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 Or better: thinking long and hard about the question "What problem is this trying to solve?" and then considering whether another tool that dumps/reads a config file at a fixed location is the best way to deal with it in the first place.
- politelemon 3y agoThe 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 3y agoLet’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.
- benatkin 3y ago#18 applies I think. I don't see a reason to think GP is just wanting to bikeshed just for the sake of bikeshedding. https://utminers.utep.edu/omwilliamson/engl1311/fallacies.htm https://utminers.utep.edu/omwilliamson/engl1311/fallacies.ht...
- bawolff 3y agoI also had the same reaction. It just doesn't seem very descriptive. Even .config would be better
- jedberg 3y agoBack 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 3y agoYou 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 3y agoMost 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.
- galleywest200 3y ago/etc/nginx and /etc/httpd are two examples that are prevalent but have nothing to do with a system's configuration.
- regularfry 3y agoDepends where you think the boundary of "the system" is.
- bawolff 3y agoThat's incorrect, those are system config (i.e. how nginx/httpd run on your system). Which is a very different type of config than being discussed here.
- xyst 3y agomaybe .self is better
- renewiltord 3y agoIn 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 https://github.com/dot-config/dot-config.github.io
- mickelsen 3y agoI support this motion.
- notatoad 3y agoI 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.
- cmckn 3y agoI tend to agree. The reason these files land in the root directory of many repos is because the multitude of tools that use them expect their file to be in $PWD, and running make or mvn or docker or npm from the root of the repo is usually convenient. Changing that paradigm needs more of a justification than tidiness, I think.
- micimize 3y agoWhile I wouldn't put Dockerfile and .rc files in the same category, the hardcoded file convention bugs me. But, can't pretty much any of these be put wherever one wishes? Like `ops/` or w/e?
- deleted 3y ago[deleted]
- notatoad 3y agoFor most of these repo-specific config, if you put it in a subdirectory then some tooling won't work properly. If your dockerfile is in ops/, the you have to tell people how to run docker build. If your .eslintrc is in ops/, then those rules will only apply to files in subdirectories of ops/...
- wkdneidbwf 3y agoi know this goes down the rabbit hole, but i think every project benefits from a makefile or other taskrunner file. even if a project is a simple “docker build ...” having done task makes it really easy to see
- rco8786 3y agoHow is this not a very, very, on-the-nose example of "sweeping the dust under the rug"
- regularfry 3y agoBecause the most important part of the problem isn't the profusion of config files, it's that as a project owner I'm not in control of the most important entry point to my own work.
- benatkin 3y agoThe alternative for a lot of things is the root directory having almost nothing in it, because the main content is already split from the top level directory by: - node monorepos by putting everything in the packages directory - python repos by putting almost everything underneath the name of the package What might help some who are annoyed by this perceived clutter is to be to jump straight into the main content in the subdirectory. Getting the other files moved out only helps it a little because you don't have to go through as many items to click or cd into the main content's directory. It doesn't remove a whole step. The steps are still 1) to go to the repo and 2) click or cd to the directory that has the main content.
- powersnail 3y agoMore like putting utensils into a drawer, as far as I can see.
- Izkata 3y agoThat's at least some sort of organization (which drawer?), this just hides the mess with no organization. If you're gonna propose tidying it up, at least propose a useful organization other than just hiding it, like from the example list of files maybe something like 3 subdirectories: installers, linters, and compilers/runners?
- powersnail 3y ago
- cyode 3y agoI’ve had a similar idea in my mental “this would be a cool convention” list: .dotfiles/ or .dots/ , strictly for getting dotfiles out of the root dir. The criteria is a little clearer compared to “config” files, which could mean a lot of things.
- kortex 3y agoWould this also apply to home directory, eg ~/.meta/.netrc? That would be neat and make backing up a system and synching configs easier. Also, what about .idea/.vscode and related IDE stuff? Those I would definitely consider "metadata". Would X/.meta/.dockerignore work the same as X/.dockerignore ? As in relative to the root as if .meta was not there? Not sure I agree with docker-compose.yml being there, but not really opposed to it either. What about Makefile or CMakeList.txt?
- JoshTriplett 3y ago> Would this also apply to home directory, eg ~/.meta/.netrc? That would be neat and make backing up a system and synching configs easier. ~/.config and ~/.local already exist for that purpose: applications should read and store configuration in ~/.config, use ~/.local/share for data, and install binaries to ~/.local/bin.
- arielcostas 3y agoI don't think ~/.meta is needed when there's the XDG config path, which by default is ~/.config For unix-like systems like Linux at least, for Windows there is the AppData directory with the same function.
- em-bee 3y agofor home directories .config, .local and .cache are gaining popularity
- z3t4 3y agoThis is such a dejavu, I remember a few years ago someone made the same initiative and succeeded to get a lot of repos/projects to place all their dotfiles in one folder, but I do not remember the name of the folder... anyone?
- dinckelman 3y agoIt'd probably make a lot more sense for it to be called `.config/`, amongst all other things, but for this to gain any traction at all, some bigger projects need to show initiative first. Everything already has like 47 potential config file names they read, so adding another one won't put a dent into the schedule
- ricardobeat 3y agoThis has been proposed yearly for a long time. See https://dot-config.github.io/ https://dot-config.github.io/ for one of the latest attempts. Hiding files under a directory is not really a solution for anything other than slightly improving file navigation, but even if you think it's valuable, the real problem is getting tools to adopt it. There is no incentive to be the first. The intermediate state is terrible - now you need to guess if a config is located at the root or this new config directory, and if your version of the tooling is able to pick up the new location.
- gurjeet 3y agoThe ToolsConfig proposal (I mentioned in another comment [1]) is specifically designed for tools and projeccts to adopt it slowly, at their own pace. [1]: https://hackernews.hn/item?id=36475364 https://hackernews.hn/item?id=36475364
- jurassic 3y agoI see no reason for this at all.
- lucideer 3y ago> This is avoid making a mess in the root directory of projects, as [this] tweet laments. Registered an entire domain name to back an idea based on a tweet, but completely missing the point of that tweet. If only they'd read the tweeter's own replies under that same tweet they could've avoided wasting their time on this. For clarity: the original tweeter was bemoaning the state of JS tooling (the busy root directory being a symptom - not the core problem). Throwing your fifty config files in a hidden subdirectory is what's typically referred to as "supporting dysfunction".
- klabb3 3y ago> Throwing your fifty config files in a hidden subdirectory is what's typically referred to as "supporting dysfunction". Hilarious expression. But we’re going even further here: standardizing dysfunction.
- thrashh 3y agoThe only thing in the root of my projects ARE these files. That’s the whole point of the root in my opinion.
- cesarvarela 3y agoThe problem is like we all want to do things slightly different but to get mostly the same results. Prediction: Once we have AI in between everything all these config files will disappear.
- wzy 3y agoWouldn't `.configs` make more sense?
- joshka 3y agohttps://github.com/bigskysoftware/dotmeta/issues/4 https://github.com/bigskysoftware/dotmeta/issues/4 --- While probably a bikeshed consideration, .config is a much more obvious name to use for this. HN thread with many agreements: https://news.ycombinator.com/item?id=36472613 Previous project suggesting .config: https://dot-config.github.io/ I'd suggest leaving this issue around and collecting thumbs up / down (Please don't comment with +1s on this, unless you have something novel to add).
- deleted 3y ago[deleted]
- zarzavat 3y agoInstead of attempting to change ALL tools to accept a config file in a non-standard location which is never going to happen, and will just lead to having files in both locations, just recode the file browsers to optionally display config files under a virtual directory. There’s surely fewer file browsers than tools.
- programmarchy 3y agoThis was my thought as well. VS Code already has files.exclude in .vscode/settings.json
- 111111IIIIIII 3y agoYeah that's what I use when I care enough
- Drblessing 3y agoThis is great! I didn't know about it. What files have you added?
- 111111IIIIIII 3y agoI actually have an extension that adds a little expandable section called "Hidden Files" at the bottom of the explorer pane, where I can open it and add a check beside the files I want to hide. In some projects, I change it at leisure, which usually means I'm hiding any files that never have any bearing on my day to day work. Sorry I don't remember the exact name of the extension.
- Drblessing 3y agoThanks!
- paulhodge 3y agoI'd suggest having them in a directory just called config/ On having it start with a dot: Why? Why would we pretend that these crucial files don't exist? On having it named meta: These files aren't "about" the project or "above" the project, they ARE the project.
- fallat 3y agoYeah hiding these files would be a huge mistake.
- benatkin 3y agoand security problem. whoops, just committed all the secrets in .meta/.env.production!
- CuriousCosmic 3y agoThank god when you commit, the editor lists all the files you've committed in the comments of the commit message.
- phanimahesh 3y agoWhat editor? There's no editor in git add . && git commit -am "made changes" /s
- CuriousCosmic 3y agohooo boy. i could feel my blood pressure spike for a brief moment before i saw the `/s`.
- ks2048 3y agoYes, but why would anyone follow this very reasonable line of thinking if you don't have a custom domain name to back it up?
- 111111IIIIIII 3y ago
- deleted 3y ago[deleted]
- dwheeler 3y agoThere's been a spec for this for a long time, with some uptake. If you want config files in one place, at least on Unix-like systems, the Free Desktop Spec recommends that config files be in $XDG_CONFIG_HOME which by default is $HOME/.config - see: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...
- TrueDuality 3y agoThere is an existing standard for this: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... It's generally really well respected by a lot of software. It's just not well known enough that its annoying. In my experience a lot of the failures are from Apple developers assuming that this is a "Linux spec".
- deleted 3y ago[deleted]
- AceJohnny2 3y agoThis has basically already been proposed via the XDG (Cross-Desktop Group) Basedir Spec in 2014 [1]. The latest version of which can be found here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... And, of course, obligatory reference to https://xkcd.com/927/ https://xkcd.com/927/ [1] surprisingly hard to find history, but Wayback Machine to the rescue: https://web.archive.org/web/20170319100840/https://specifications.freedesktop.org/basedir-spec/ https://web.archive.org/web/20170319100840/https://specifica...
- ajsfoux234 3y agoThe XDG spec appears to be specifying user-wide/system-wide configuration files, but the post is about organizing files specific to an individual project or repository. (edit: related: https://news.ycombinator.com/item?id=36474981 https://news.ycombinator.com/item?id=36474981 , https://news.ycombinator.com/item?id=36474943 https://news.ycombinator.com/item?id=36474943 )
- Skunkleton 3y agoEven better would be to have tools share configuration files. Plain make files don't have this problem. Build scripts also don't have this sort of problem. Ofc once you start with autotools, things go pretty bad. Build scripts usually suck once a project is larger than a toy. Golang has an interesting approach.
- creatonez 3y agoI wouldn't adopt it purely because of the name ".meta". Some folders and files are inevitably going to straddle the line between "data" and "metadata"
- gurjeet 3y agoHere's a proposal I have developed to solve the same problem: https://www.toolsconfig.org/ https://www.toolsconfig.org/ The onus is on the tools developers to adopt this change. And the proposal allows for the gradual, graceful migration from current status to a place where all such files are stored in a central location. The directory name `.toolsconfig`, or `.tc` is the best I could recommend, since `config` or `.config` can be safely assumed to be already in use. Using 'tools' in the directory name also makes it explicit as to whose config files are stored in there; tools developers use, not the config of the projecct itself. Edit: The Git repo of the proposal is hosted on Github. Feel free to propose any changes or improvements to the proposal or the algorithm. https://github.com/DrPostgres/ToolsConfig/ https://github.com/DrPostgres/ToolsConfig/ https://www.toolsconfig.org/ https://www.toolsconfig.org/
- cryptos 3y agoI don't like "tc" because it is not self-explanatory and somewhat cryptic to me. The argument on name collisions is valid, although even "toolsconfig" is not 100 % safe.
- Drblessing 3y agoGreat proposal!
- Drblessing 3y agoFantastic idea
- Drblessing 3y agohttps://xkcd.com/927/ https://xkcd.com/927/
- deafpolygon 3y agoI prefer $PROJ/config/ (or even /settings/) -- this is self-explanatory. $PROJ/.meta is not a standard practice and would be confusing (what's so meta?). Why use dotfile naming? That's just old practice that no longer needs to be used. We're not hiding anything (and why should we?). Configurations should never be hidden. I feel like the main reason why dotfiles exist is because they typically got put in your $HOME and that would just litter your file manager's view.
- paxys 3y agoSome immediate problems with this idea: - A lot of files they mention aren't random metadata but critical parts of the project. Stuff like package.json, Dockerfile, build configs etc. should not be hidden away. - For a lot of other files like .git, .gitignore, .dockerignore their exact path matters to their operation, especially since a lot of them are hierarchical as well. The author's sole problem seems to be that their project root is too cluttered, and some people here have a better suggestion - fix it at the UI layer instead. Have VS Code (or whatever other file browser) automatically put these files in a virtual sub-folder.
- deleted 3y ago[deleted]
- flemhans 3y agoIt's like the folder named "mess" I have on my desktop. Keeps the desktop nice and tidy! Folder contains all sorts of random shit, though.
- cryptos 3y agoI've already thought about creating such a folder on my system. I'm happy to learn that I'm not alone :-)
- rkta 3y agoRelevant xkcd: https://xkcd.com/1077/ https://xkcd.com/1077/
- Spivak 3y agoThis pattern is also sometimes called a doom box. They're useful for when you need to make forward progress on task #1 (tidying the desktop) but don't have the energy to do task #2 (actually deal with the random crap).
- cxr 3y agoHaving the proposed directory actually named "mess" is probably a much better idea than a semi-respectable sounding name like ".meta". A constant reminder that most of this stuff is a joke to begin with—that "none of this is necessary; it is merely customary", as Jef Raskin once put it—wouldn't be the worst thing in the world.
- fzeindl 3y agoI have to say that if the JavaScript build ecosystem wasn't such a mess that needs reinvention twice a years, this would hardly be necessary.
- cxr 3y agos/JavaScript/NPM/
- Communitivity 3y agoI think this is a good concept, and I'd like to offer some feedback. Things I like: - I agree that something should be done - I think having a wall of honor on your site is a good way to promote adoption - I think you make some good arguments Things I question: - .meta - As others have pointed out, it's not metadata about the project, it's part of the project. Also, as others have noted, having this be a dot file will unnecessarily hide the directory in some circumstances. - There is no org-based namespacing in the .meta approach - A wall of honor is probably not enough to drive adoption Recommendations: - I think another form of adoption driver is to discuss it on the mailing lists of 2-3 large open source projects, get them to buy into you submitting a PR for this as a non-breaking enhancement (if files not found in current dirs, look in .meta; if files not found at all create them in .meta), and then follow through with the PR for each. Some candidates are VS Code, NPM, NetBeans, Maven, and Cargo. - etc seems a natural project config directory name. /etc is for system config files, ${BASEDIR}/etc is for project config files. There may be some conflicts here with projects already using etc, but the file's should conflict. - what I think we need is a unified project metadata file, then links in that file could be traversed to the tool specific files and it wouldn't matter where they were - they wouldn't need to be in the root directory. Description of a Project (DOAP) [1] was a good start toward this, but the last time it had more than 1 PR a year was in 2018. There's no JSON format. [1] https://github.com/ewilderj/doap/wiki https://github.com/ewilderj/doap/wiki
- anagram666 3y agoWTF!?! This already exists. Why you are reinventing the wheel again?!? A lot of programs already implement the XDG Base Directory Specification[1], putting the configuration in the .config directory. These programs should just follow the ALREADY EXISTING specification. If you want to understand it, the arch wiki[2] have a good explanation about all the directories. [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... [2] https://wiki.archlinux.org/title/XDG_Base_Directory https://wiki.archlinux.org/title/XDG_Base_Directory
- mcint 3y agoThis proposal calls for developers to adopt a standard within their projects, as opposed to addressing where configuration files for installed software should live within a user's home directory. https://dotmeta.org https://dotmeta.org, note projects This site exists to advocate that software libraries look for their config files in .meta directories of projects. This is avoid making a mess in the root directory of projects, as this tweet laments. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-..., note users ## Basics The XDG Base Directory Specification is based on the following concepts: - There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.
- mochaa 3y agoWe already have language-specific files to define those keys, such as `package.json`, `pyproject.toml`, `Cargo.toml`, `deno.json` (and many more). I don't see why you shouldn't integrate it into your project configuration instead of pretending that _'this is fine'_ and hiding all of it in a directory. also: <https://xkcd.com/927 https://xkcd.com/927>
- JoeyBananas 3y agoI don't like this because there are never more than a "human comprehensible" number of hidden files/directories in the top level of the project.
- mcint 3y agoThis looks like a job for—the debate platform. As an excuse to try mapping out a debate in some depth, I set up a Discussion, “Should software projects adopt a standard subdirectory for files for configuration, tools, & metadata?”[1] on kialo.com, that others can explore or add to. [1]: https://www.kialo.com/should-software-projects-adopt-a-standard-subdirectory-for-files-for-configuration-tools--metadata-63437 https://www.kialo.com/should-software-projects-adopt-a-stand...
- moritzwarhier 3y agoIf this was implemented, what kinds of files would have the privilege to live at the root of the project? In case it's just folders left, the root folder as a location for project-scoped configuration files still has the advantage that nobody has to look for it?
- ycnuri 3y agoWhat about yard - "yet another root directory", if naming matters? The term also has a meaning that "an area ... used for a special purpose". As you may use your back "yard" tidying your households from time to time, it is quite aligned with the idea of .meta directory - tidying things up?