How to avoid conflicts between lockfile/pin settings between global and project configs?

[powerman]

If I change some of global settings like experimental, lockfile and pin in ~/.config/mise/config.toml because I need them for managing global tools, then it looks like I must restore them to default values in ~/.mise.toml - otherwise some projects may breaks. Is this correct? If yes, then it probably worth mentioning in the docs.

[jdx]

I must restore them to default values in ~/.mise.toml

I don't understand what this means

[powerman]

Hmm. Is this means I can't have any predictable settings for global tools - they'll depends on cwd?

At a glance this is an issue only for mise up.
Maybe it makes sense to add mise up -g to make it work in similar way to mise use and thus take in account only global config file?

Anyway, the feature I miss for global tools is a history of version changes. Trivial log file in mise state (or data) dir for all install/remove/upgrade actions will work, but it doesn't exists. And the reason is trivial: if some tool will broke after mise up I'd like to be able to find out which (working) version of the broken tool I've used before.

So, I'm trying to use lockfile settings for global tools (together with daily backups or a git repo in a global config dir) just to create this version-history.

[jdx]

Maybe it makes sense to add mise up -g to make it work in similar way to mise use and thus take in account only global config file?

All commands in mise use local and global config files to determine the settings for a given execution, mise use and mise up behave identically here. Settings resolution is early in mise's load process before it even knows what command it will launch.

Anyway, the feature I miss for global tools is a history of version changes. Trivial log file in mise state (or data) dir for all install/remove/upgrade actions will work, but it doesn't exists. And the reason is trivial: if some tool will broke after mise up I'd like to be able to find out which (working) version of the broken tool I've used before.

You might be able to accomplish this with MISE_LOG_FILE, not sure though.

[powerman]

MISE_LOG_FILE currently does not contain enough messages on info level: no mise rm actions and even no "Installed binary into" messages from Go backend (I hope this will be fixed when it's out of experimental state). But yeah, it probably a better way to go than trying to misuse lockfile feature. Thanks for the hint!

As for the settings usage - I need some more time to research how it works now and how to use it correctly before continue this discussion.

[jdx]

I can tell you right now this behavior of settings will not change. What we could do is perhaps provide some customization for lockfile, like maybe making it lockfile = 'write_only' which would only update existing lockfiles and not create them if they don't exist.

[powerman]

I can tell you right now this behavior of settings will not change.

That's fine. I didn't ask for this, I'm just trying to figure out how to use Mise in a safe way: corner cases, workarounds, best practices.

Here is my understanding about lockfile and pin settings. Please tell me if I get anything wrong.

• To make sure all project's developers use same tool versions:
  • It's recommended to set lockfile = true in a project config:
    • It guarantees same tool versions for all developers.
    • It let you declare restrictions for mise up in a config.
  • If it's impossible to set lockfile = true for some reason (e.g. because it's an experimental feature or project uses too old mise) then it's recommended to set pin = true:
    • This will reduce the likelihood of different developers using different versions.
    • You'll have to manually control that there are no version prefixes used in a configs.
• It's not recommended to set both lockfile = true and pin = true in a project config:
  • This will prevent you to set prefix by mise use and won't make anything better in return.
• It's recommended to always run mise use -g with --pin or --fuzzy:
  • Otherwise if it's run in a project's dir then project's setting pin will apply (which is usually not what you want for global tools).
• It's not recommended to set neither lockfile = true nor pin = true in a global config:
  • If any of these settings is enabled in a global config then in each projects requiring same settings to be disabled you'll have to disable these settings using *.local.toml config. But chances are you'll forget to do this in some projects and/or forget to remove this from *.local.toml if project will decide to enable these settings later.
  • There is not much sense in using lockfile = true in a global config: a "global" tools are actually "local" for your system, so you don't need to sync their versions.
    • However, in theory there is a case you may wanna sync tools between your own systems (e.g. desktop/laptop).
  • The pin = true in a global config has no real use at all.
• When you move between projects with and without lockfile = true global tools may unintentionally switch between actual and outdated version (and even became not available at all - but that's probably related to mise hook-env: PATH is not updated after mise uninstall #2876 and may be fixed).

Steps to demonstrate last point:

1. Global config has TOOL = "latest". Currently installed: TOOL@1. There is no lock-file in a global config dir.
2. Enter project A which has lockfile = true.
3. Run mise i. This will result in creating lock-file in a global config dir with TOOL = "1".
4. Leave project A (be outside of projects or enter a project which don't use lockfile = true).
5. Run mise i TOOL@2. The global tool will upgrade to TOOL@2.
6. Optional step: mise rm TOOL@1 (or mise prune). It won't change TOOL version in use.
7. Enter project B which also has lockfile = true.
8. This result in changing current version of TOOL from 2 to 1 (or make TOOL unavailable at all if version 1 was removed on step 6).

The overall behaviour "entering project B may result in start using an outdated lock-file for global tools which was created long time ago while working on project A" looks really non-intuitive. Maybe it's possible to fix this by changing how lockfile setting work for global tools. Maybe auto-removing (maybe just global or maybe all) lockfile when lockfile option is not enabled will solve this issue. Or maybe global lockfile shouldn't be created at all.

[jdx]

just don't set lockfile = true in a project. Settings generally should be configured globally since that's their behavior.

[powerman]

just don't set lockfile = true in a project

Not sure I get how this is supposed to work:

• Developers can't control settings in every project they're working on. Sometimes it's just a fork of 3rd-party project used to prepare a PR. Sometimes it's work project which must follow company's policy which might (and should IMO) say "use lockfile=true". (Trying to "fix" settings in *.local.toml manually in each such project has issues I've already mentioned above.)
• How I (as a person in architect/team lead role responsible for making such a decisions) should ensure every developer on my project uses same tool versions without adding lockfile=true in project's config? Asking every developer to set their own global settings is… unreliable at best, but also might conflict with other needs of a developer.

[powerman]

Or you mean "don't set lockfile = true in a project AND don't use version prefixes in configs"? This will work for a work project, just a bit less convenient. But it won't help with 3rd-party projects which may use whatever they want in their configs.