from Hacker News

The .meta directory: let's tidy things up

by geoffeg on 6/25/23, 9:08 PM with 140 comments

  • by paulhodge on 6/26/23, 1:43 AM

    I'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.

  • by politelemon on 6/25/23, 10:27 PM

    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.

  • by notatoad on 6/25/23, 10:56 PM

    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.

  • by gurjeet on 6/26/23, 3:19 AM

    Here's a proposal I have developed to solve the same problem: 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://www.toolsconfig.org/

  • by joshka on 6/26/23, 1:01 AM

    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).

  • by ricardobeat on 6/25/23, 11:31 PM

    This has been proposed yearly for a long time. See 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.

  • by Communitivity on 6/26/23, 3:03 PM

    I 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

  • by lucideer on 6/25/23, 11:36 PM

    > 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".

  • by paxys on 6/26/23, 9:17 AM

    Some 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.

  • by dstroot on 6/25/23, 10:26 PM

    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.

  • by TrueDuality on 6/26/23, 2:20 AM

    There is an existing standard for this: 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".

  • by AceJohnny2 on 6/26/23, 2:31 AM

    This 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-...

    And, of course, obligatory reference to https://xkcd.com/927/

    [1] surprisingly hard to find history, but Wayback Machine to the rescue: https://web.archive.org/web/20170319100840/https://specifica...

  • by eyelidlessness on 6/25/23, 10:25 PM

    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.

  • by zarzavat on 6/26/23, 1:42 AM

    Instead 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.

  • by deafpolygon on 6/26/23, 4:48 AM

    I 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.

  • by rco8786 on 6/25/23, 10:59 PM

    How is this not a very, very, on-the-nose example of "sweeping the dust under the rug"

  • by flemhans on 6/26/23, 11:24 AM

    It'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.

  • by dinckelman on 6/25/23, 11:27 PM

    It'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

  • by cyode on 6/25/23, 11:00 PM

    I’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.

  • by joeframbach on 6/25/23, 9:59 PM

    Why not `.config`?

  • by jedberg on 6/25/23, 10:43 PM

    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).

  • by dwheeler on 6/26/23, 2:15 AM

    There'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-...

  • by rektide on 6/25/23, 10:13 PM

    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.

  • by kortex on 6/25/23, 11:09 PM

    Would 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?

  • by fzeindl on 6/26/23, 12:43 PM

    I 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.

  • by ycnuri on 6/27/23, 12:28 PM

    What 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?

  • by Skunkleton on 6/26/23, 2:39 AM

    Even 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.

  • by z3t4 on 6/25/23, 11:17 PM

    This 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?

  • by mcint on 6/26/23, 9:37 PM

    This 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-stand...

  • by creatonez on 6/26/23, 2:44 AM

    I 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"

  • by JoeyBananas on 6/26/23, 9:26 PM

    I 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.

  • by renewiltord on 6/25/23, 10:51 PM

    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

  • by wzy on 6/26/23, 12:03 AM

    Wouldn't `.configs` make more sense?

  • by moritzwarhier on 6/26/23, 9:54 PM

    If 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?

  • by thrashh on 6/25/23, 11:40 PM

    The only thing in the root of my projects ARE these files. That’s the whole point of the root in my opinion.

  • by jurassic on 6/25/23, 11:33 PM

    I see no reason for this at all.

  • by cesarvarela on 6/26/23, 12:31 AM

    The 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.

  • by mickelsen on 6/25/23, 10:51 PM

    I support this motion.

  • by Drblessing on 6/26/23, 3:27 AM

  • by paulddraper on 6/26/23, 3:29 AM

    Why not tools/ ?

  • by Drblessing on 6/26/23, 3:21 AM

    Fantastic idea

  • by xyst on 6/25/23, 10:47 PM

    maybe .self is better

  • by mochaa on 6/26/23, 4:21 PM

    We 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>

  • by anagram666 on 6/26/23, 3:41 PM

    WTF!?!

    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-... [2] https://wiki.archlinux.org/title/XDG_Base_Directory