Option to specify path to configuration file

[pawamoy]

Context

Follow-up of #263. Now that config files are supported, I'd like to be able to specify a different path for the config file. The reason is that I put all tools config files into a config folder (name is not important), and call linting tools from my task runner, which takes care of passing the right path to the config file.

Proposal

Adding a simple option to the CLI like mdformat -f config/mdformat.toml (-f because -c is more similar to --check). Long option could be --config or --config-file.

Tasks and updates

No response

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[hukkin]

Thanks for the issue!

I think adding this might be ok. I'm a bit unsure about this for concerns about global config similar as here. This is much better in that the config is explicitly specified so not so much a side effect.

This does raise the question of how to determine root directory for file exclusions. Is it current working directory or the parent directory of the specified config file? We have to know this before implementation.

[pawamoy]

This is much better in that the config is explicitly specified so not so much a side effect.

Strongly agree. I've never seen anyone using global configuration for tools, as project usually ship their own config, and the config usually depends on the project anyway, so global config rarely make sense. Then it's true that a -f config option would re-enable global configuration, but as you mentioned, you have to explicitly pass the option, and we're responsible adults 😄 Note that I'm not planning on using this option for global config 🙂 I simply prefer organizing my config files in a subfolder (and I generally dislike default config names that start with a dot).

This does raise the question of how to determine root directory for file exclusions. Is it current working directory or the parent directory of the specified config file? We have to know this before implementation.

Indeed, it's important to know that before starting to work on the feature 🤔

Computing things as relative to the configuration file (or rather its parent folder) means you don't have to get the Git root repository, and running the tool will work from anywhere in the repo (doesn't depend on the CWD either). That also means you have to update the file if you move it, but I believe this rarely happen, so it's not a big issue.

Config-relative paths make sense for .editorconfig for example, because you can have many such files in your repo. mdformat will probably accept only one file, so maybe it doesn't make as much sense, and repo-root-relative or CWD-relative paths will be easier to implement / more intuitive. Many tools depend on the CWD and users generally don't care, as most of the time commands are run from the root of the repository anyway.

Looking at the tools I currently use (ruff, pytest, coverage, mypy), it seems none of them is config-relative. pytest does write some cache files next to the config file instead of the repo root though.

Ultimately I think it depends on the tool, and what you're most comfortable with. Sorry, I'm not super helpful here 😄 Anything you choose is fine by me 🙂

[rpdelaney]

Strongly agree. I've never seen anyone using global configuration for tools, as project usually ship their own config, and the config usually depends on the project anyway, so global config rarely make sense.

ruff (contrary to your comment), mypy (ditto), black, and flake8 all support global configuration files. While these tools don't mandate that you use this functionality -- as is evinced by your not knowing it exists (win!) -- lots of people make use of it and it's no big deal.

I find that the global configurations are useful to give me the benefits of linters and formatters with a consistent configuration that I'm used to when working in codebases I don't share with others.

[pawamoy]

I see, my bad for assuming few people use global configs 😄 It wasn't a good assumption since I obviously wouldn't know what everyone is doing on their own system 😅