.mise.toml -> mise.toml

[jdx]

Recently, @rsyring had a wonderful, simple suggestion that we support mise.toml in addition to .mise.toml. This turned out to be a remarkably simple idea that I'm shocked nobody (that I can recall) had proposed we do before. It makes mise a lot easier to work with and has become my favorite way of specifying the config.

I like it so much I think it should be the new default over .mise.toml—meaning it's what we use in the docs and if you run mise use with no config it would create a mise.toml file. Though if you have a .mise.toml file it should just reuse that.

I also think this would work well for tasks which would benefit from being located in mise/tasks over .mise/tasks—though in that case I also have long wondered if we should be using something flatter like mise-tasks or just tasks.

Anyone have any arguments why we shouldn't do this?

[rsyring]

I think its a great idea to have mise.toml be the default. I think discoverability is really important and this helps DX.

Re: mise folder

• plain tasks: runs the risk of conflicting with projects that already have a tasks folder. Maybe that's not that big of a deal. I like that its simple and straightforward.
• mise-tasks: flat is better than nested. Seems weird if mise/config.toml is still a thing? If other mise files/folder show up eventually, they all are top level or go in mise/?
• mise/tasks: while there is one nested layer here, I like that everything is in the same folder and there is room for future files/folders without polluting the top-level of the project. If I use a mise folder, then mise.toml usually goes to mise/config.toml although with mise.toml being the default now, I could see just leaving that in the root even if using a mise folder.

FWIW, as I wrote all that out, I started to like the idea of mise.toml and tasks/ in project root. You could deal with the conflict situation by only considering files in tasks/ if [.]mise/tasks/ doesn't exist.

[jdx]

One issue is it recurses all the way up the tree. It's also not something simple to offer a way to get out of

[rsyring]

One issue is it recurses all the way up the tree.

Maybe the bare tasks as a place for mise tasks is only valid when its next to the mise config file? Or, if mise has the concept of a "project root" then in the project root?

[jdx]

I think if we go that route it would be better to just have an explicit field to define the directory:

[settings]
tasks_dir = './tasks'

[rsyring]

Just had a thought when working with a mise/tasks folder. Could tasks just go in mise and get rid of the tasks? Anything in the mise folder that is executable becomes a task.

[CEbbinghaus]

I'm in strong support of having a configurable tasks dir with a sane default; "tasks" sounds good

[steveno]

I like the idea of having a mise directory to hold a config.toml and the tasks/. Without any good objective reason, though, I do prefer .mise/.

[syhol]

• +1 on mise.toml be the default
  • None of the following are hidden: Makefile, Dockerfile, flake.nix, cargo.toml
• +1 on a configurable tasks_dir
• -1 on defaulting tasks_dir to mise/tasks
  • If I wanted a minimal project folder I would use .config/mise/tasks
  • If I wanted a prominent task folder I would use tasks/ or something similar (see below)
• Neutral on defaulting tasks_dir to tasks/
  • I see a lot of projects use bin/, script/, or scripts/ and almost none use tasks/

[powerman]

• I see a lot of projects use bin/, script/, or scripts/ and almost none use tasks/

@syhol Searching GitHub result in 508000 files found in a tasks/ directory in repo root. So, "almost none" sounds a bit incorrect.

[powerman]

Current list of supported config file names (from https://mise.jdx.dev/configuration.html) looks really confusing:

.mise.local.toml
mise.local.toml
.mise.$MISE_ENV.toml
mise.$MISE_ENV.toml
.mise.toml
.mise/config.toml
mise.toml
mise/config.toml
.config/mise.toml
.config/mise/config.toml

• It isn't clear which ones to use (or not use) and in which cases prefer one to another.
• For new users (like me) it isn't clear which ones are "old" (legacy) and which ones are "new" (recommended for new projects) - until user finds current discussion, of course.
• The above list differs from another list on https://mise.jdx.dev/profiles.html:

.config/mise/config.toml
mise/config.toml
mise.toml
.mise/config.toml
.mise.toml
.config/mise/config.local.toml
mise/config.local.toml
mise.local.toml
.mise/config.local.toml
.mise.local.toml
.config/mise/config.{MISE_ENV}.toml
mise/config.{MISE_ENV}.toml
mise.{MISE_ENV}.toml
.mise/config.{MISE_ENV}.toml
.mise.{MISE_ENV}.toml
.config/mise/config.{MISE_ENV}.local.toml
mise/config.{MISE_ENV}.local.toml
.mise/config.{MISE_ENV}.local.toml
.mise.{MISE_ENV}.local.toml

• These lists declare priority in different ways (top-down or down-top).
• First list does not mention all configs listed in a second list (it may make sense if it won't include MISE_ENV configs at all, but it has some but not all).

While I agree using mise.* instead of .mise.* might be a good idea, at the moment it results in a chaos.

To me it doesn't looks like both name styles should co-exists. Here are some ideas:

• Mise should use new mise.* by default in a dir without any Mise config files/dirs (right now mise use still creates .mise.toml instead of mise.toml).
• Mise shouldn't work if there are both .mise{.*,/} and mise{.*,/} in same directory: in this case it should give up with an error and ask user to merge/rename them and/or propose to do this automatically.
• Probably same should apply to global ~/.config/mise/config.toml and ~/.config/mise/mise.toml (prefer first one by default and propose to rename/merge second into first one)?

As a result we should get this (with extra note "legacy names .mise.* and .mise/ are supported as long as there are no new names mise.* and mise/):

.config/mise/config.toml
mise/config.toml
mise.toml
.config/mise/config.local.toml
mise/config.local.toml
mise.local.toml
.config/mise/config.{MISE_ENV}.toml
mise/config.{MISE_ENV}.toml
mise.{MISE_ENV}.toml
.config/mise/config.{MISE_ENV}.local.toml
mise/config.{MISE_ENV}.local.toml
mise.{MISE_ENV}.local.toml

[jdx]

dotfiles config files are not legacy or discouraged and I do not agree that should be the case, they're simply no longer the default. You are correct that mise use hasn't been updated yet but that has been on my list to take care of. I agree the documentation is overwhelming and we could probably represent this information better. The functionality in general though I think is useful and allows people to configure mise in ways that work for their codebase. Some may want to group config files in a subdirectory, some may not.

[powerman]

My suggestion won't prevent people to configure mise in ways that work for their codebase. If they like to use .mise - fine, mise - also fine. Just don't use both at once - this will likely make an issue for them, not for mise.

How about adding an optional feature to mise: show warning (in a way I mentioned above) if both kinds of names are used in the same dir? If someone really wants to use both and knows what he is doing he will just disable this warning in one of his configs. Just keep this feature enabled by default, to help people keep their configs clean.

[jdx]

I see no reason to discourage people from using mise and .mise in the same project. Yes it is strange, but it's obviously strange and doesn't require us to tell them that.

[rsyring]

@powerman you may also be missing that mise configuration isn't just in the current project but can be done in every directory above the active one. You also don't need to guess what configuration files are in use as mise doctor will show you:

config_files:
  ~/.config/mise/config.toml
  ~/projects/.mise.toml
  ~/projects/foobar-src/mise.toml
  ~/projects/foobar-src/mise.local.toml

I might want hidden configs personally but work in a project that puts the config at the top level.

The flexibility is a benefit, although I agree with @jdx that the documentation could be improved to help new users with a "recommended way" they can use initially.