Add support for "mise-en-place"

[amarcadet]

Tell us more.

Mise is mostly a clone of "asdf" see: https://mise.jdx.dev/comparison-to-asdf.html

It supports .tool-versions file but also offers a new file format .mise.toml, see: https://mise.jdx.dev/configuration.html

It would be great to support this dependency manager

[github-actions[bot]]

Hi there,

You're asking us to support a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.

Once the questionnaire is filled out we'll decide if we want to support this new manager.

Good luck,

The Renovate team

[jvizier]

• Update from "jdx" main author of mise-en-place
• From Mise support in renovate jdx/mise#1940
• I read the documentation for adding a package manager.

New package manager questionnaire

Did you read our documentation on adding a package manager?

• I've read the adding a package manager documentation.

Basics

What's the name of the package manager?

"mise-en-place" or simply "mise"

What language(s) does this package manager support?

Virtually all of them.

How popular is this package manager?

It's ~200th place in Homebrew across all formulas.

Does this language have other (competing?) package managers?

• Yes: asdf, vfox, proto, aqua
• No.

What are the big selling points for this package manager?

Performance, developer experience. Mise's goal is to become the "front-end to your dev env" with the ultimate goal of being the standard choice for developers at organizations and in open source projects to adopt for running their codebases locally.

Explain how this package manager is different from existing ones.

Mise focuses on DX first. Other projects try to optimize for things like stability, cross-platform support, or hardened security models—while these are also things mise strives to achieve they come second after DX at least right now. Compared to asdf, mise is a more ambitious project with a broader feature set targeting things like dev environment management and task execution.

Detecting package files

What kind of package files, and names, does this package manager use?

• asdf's .tool-versions files
• mise's .mise.toml files
• "legacy version files" https://mise.jdx.dev/configuration.html#legacy-version-files

Which fileMatch pattern(s) should Renovate use?

Probably just .mise.toml and .config/mise/config.toml to start, there are others but not all would make sense in the context of renovate (like .mise.local.toml and .mise.staging.toml).

Do many users need to extend the fileMatch pattern for custom file names?

• Possibly, users can use custom filenames, or "environment-specific" config files like .mise.production.toml.
• No.

Is the fileMatch pattern going to get many "false hits" for files that have nothing to do with package management?

Not for .mise.toml. I doubt anyone would use that name for anything else and mise would throw errors if it found one.

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

Some translation needs to be done here since renovate is for package management but mise isn't a package manager, it's a tool manager. For that there is some capability for using path:~/some/path to use tools in a local directory. This isn't a super popular feature, and it's usually used for custom compiled tools—not something where a tool is inside of a project. That said, I'm sure at some point people would try to accomplish something like this.

That said, I don't think renovate needs to do anything special for that aside from just knowing it's a valid configuration. It probably makes sense just to not touch it.

Package file parsing method

The package files should be:

• Parsed together (in serial).
• Parsed independently.
  I don't really understand what this is asking. I think it's whether each config file can be parsed independently to which the answer is
  "yes". That said, it is possible for parsing of files to change based on when the parsing happens... but this is a pretty complex
  behavior and I don't see it impacting renovate in any significant way. This would be around something like having "poetry" in a local
  config file that uses "python" from a global one. This couldn't be reversed since poetry depends on python being installed.

Which format/syntax does the package file use?

• JSON
• TOML
• YAML
• Custom (explain below)

How should we parse the package files?

• Off the shelf parser.
• Using regex.
• Custom-parsed line by line.
• Other.

Does the package file have different "types" of dependencies?

• Yes, production and development dependencies.
• No, all dependencies are treated the same. — though separate .mise.production.toml files are supported. That's just an arbitrary name that is read from the MISE_ENV env var.

List all the sources/syntaxes of dependencies that can be extracted

Describe which types of dependencies above are supported and which will be implemented in future

Versioning

What versioning scheme does the package file(s) use?

One that is difficult to explain. It's sort of like a "prefix" match where "20" matches to things like "20.1.0" or "20.0.1" but not "21.0". The logic is quite complex in order to work reasonably well across every language. As of this writing the logic is consistent across languages but I believe that will not always be the case. Some languages likely will end up using completely different logic.

Does this versioning scheme support range constraints, like ^1.0.0 or 1.x?

• Supports range constraints (for example: ^1.0.0 or 1.x), provide details.
• No.

Lookup

Is a new datasource required?

• Yes, provide details.
• No.

It's different for each language. There is a service that mise uses internally to "cache" versions of popular languages. I'm not sure it's a good idea to use it for renovate since I am not ready to guarantee that it will always be around or have the same behavior.

Will users want (or need to) set a custom host or custom registry for Renovate's lookup?

• Yes, provide details.
• No.

This is also different for each language. Some languages provide a mechanism for this, some don't. There isn't consistency in how that configuration is done either.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed.
• In the package file(s), provide details.
• In some other file inside the repository, provide details.
• User needs to configure Renovate where to find the information, provide details.

Are there any constraints in the package files that Renovate should use in the lookup procedure?

• Yes, there are constraints on the parent language (for example: supports only Python v3.x), provide details.
• Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details.
• Yes, some other kind of constraint, provide details.
• No constraints.

Will users need the ability to configure language or other constraints using Renovate config?

• Yes, provide details.
• No.

Artifacts

Does the package manager use a lock file or checksum file?

• Yes, uses lock file.
• Yes, uses checksum file.
• Yes, uses lock file and checksum file.
• No lock file or checksum.

Is the locksum or checksum mandatory?

• Yes, locksum is mandatory.
• Yes, checksum is mandatory.
• Yes, lock file and checksum are mandatory.
• No mandatory locksum or checksum.
• Package manager does not use locksums or checksums.

If lockfiles or checksums are used: what tool and exact commands should Renovate use to update one (or more) package versions in a dependency file?

Package manager cache

Does the package manager use a cache?

• Yes, provide details.
• No.

Mise has an internal cache. It's not intended to be used by anything else. Perhaps this could be revisited if we had a use-case for making the cache distributable or something though.

If the package manager uses a cache, how can Renovate control the cache?

• Package manager does not use a cache.
• Controlled via command line interface, provide details.
• Controlled via environment variables, provide details.

Should Renovate keep a cache?

• Yes, ignore/disable the cache.
• No.

Not sure what a renovate cache is frankly.

Generating a lockfile from scratch

Renovate can perform "lock file maintenance" by getting the package manager to generate a lockfile from scratch.
Can the package manager generate a lockfile from scratch?

• Yes, explain which command Renovate should use to generate the lockfile.
• No, the package manager does not generate a lockfile from scratch.
• No, the package manager does not use lockfiles.

Mise does not currently use lockfiles but this is an idea that's come up several times to improve reproducibility. I think mise will have it at some point but there aren't near-term plans for this.

Other

What else should we know about this package manager?

It may be worth exploring how renovate could integrate with mise tasks—either by having a mise run renovate task or a hook for renovate to execute tasks. Happy to brainstorm on this as tasks are new and can very much still be improved.

[rarkins]

Converted to feature request issue: #28918