Support Mise as Python provider

[jnk22]

• I have searched the issues (including closed ones) and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.
• I am willing to lend a hand to help implement this feature.

Feature Request

Hi @justinmayer, first of all, thanks for your great plugin!

I have been using virtualfish with asdf for quite a while, but recently replaced that with mise.

mise is more-or-less a drop-in replacement for asdf, but unfortunately just aliasing it does not seem to work as mise plugin list does not output Python as a plugin, as that one is "built-in":

mise plugin list

haskell
usage

Trying to add the Python feature does not work, as it is built-in already:

mise plugins add python

mise python is a core plugin and does not need to be installed
mise Run with --verbose or MISE_VERBOSE=1 for more information

As virtualfish checks for Python being in the output of asdf plugin list, this does not work:

set -l asdf_plugins (asdf plugin list)
if contains python $asdf_plugins
    ...
end

Are you interested in supporting mise with virtualfish?

---

I currently see three possibilities to allow using virtualfish with mise:

1. Implement direct support for mise the same way other tools are supported (preferred), or
2. Require users to alias mise with asdf such as alias asdf="mise" and change the behavior of requiring Python to be installed as a plugin (untested), or
3. Do not change anything and users could probably still alias mise with asdf, but need to use a wrapper around mise|asdf plugin list to also include Python (untested)

I guess all approaches have its pros and cons that I would be happy to discuss further if you are interested.

I have already implemented the first approach as jnk22/virtualfish at feat-support-mise.
This probably lacks the extended coloring support for the command vf ls --details, and potentially others that I am currently not aware of.
Also, direct support for mise should be extended with mise-specific configuration files such as ~/.mise.toml.

Either way, I would be happy to implement missing features if you want to support mise in the future.

[justinmayer]

Hi Jannik! Many thanks for your proposal to add Mise support to VirtualFish, as well as for your patience. Just this morning I finally found time to install Mise and experiment with it, and so far I am enjoying the experience.

I completely agree that we should add direct support for Mise, and your initial implementation looks like a good start. I think the next step should be to retrieve the target Python interpreter version numbers from Mise’s global configuration file at ~/.config/mise/config.toml. Using the following file as an example…

[tools]
node = "22"
python = ["3.13", "3.12", "3.11", "3.10", "3.9"]

… we should add a stanza that parses that file and extracts the target Python version numbers. This is somewhat complicated by the fact that Mise supports specifying both "3.13" and "3.13.1", whereas the current asdf-specific code assumes that ~/.tool-versions will contain only specific/full version numbers (e.g., "3.13.1"). So I imagine we will want to support both "3.13" and "3.13.1" specifiers in ~/.config/mise/config.toml.

Perhaps the best solution is to create several new VirtualFish internal functions. For example:

__vf_get_target_python_versions: This function should look for files that specify target Python interpreter versions in places like ~/.config/mise/config.toml, ~/.tool-versions, et cetera, and then parse the relevant file to extract and return the list of target Python version numbers. As you have doubtless already seen, this is currently only handled for ~/.tool-versions inside of the __vf_ls function.

__vf_get_latest_python_versions: This function should return a dictionary of the currently-supported Python versions, such as {"3.13": "3.13.1", "3.12": "3.12.8"}, et cetera). If you look at the output of curl https://endoflife.date/api/python.json | jq, you will see that it contains all the information we should need. We can compare the current date to the EOL date to determine the list of officially-supported Python versions (which as of this writing is the same as the list of major Python versions in the configuration file above). Then we can look up the current point release for each major Python version (3.13 → 3.13.1, 3.12 → 3.12.8, et cetera).

__vf_expand_python_version: This function should check each parsed version number from the output of __vf_get_target_python_versions, and if only the major version is specified (e.g., 3.13), return the expanded version based on the output of __vf_get_latest_python_versions (e.g., 3.13.1). If on the other hand the target version was specified using a full version number (e.g., 3.13.1), then just return that same version number.

With that information at hand, we can then compare the virtual environment’s Python interpreter version number (e.g., 3.12.7) to the latest version number (e.g., 3.12.8) and then take the appropriate action: display in a different color, upgrade to the latest version, et cetera.

This probably sounds a lot more complicated than I expect it will actually be to implement. In any case, is this something you would still be willing to assist with? Your help would be greatly appreciated! 😊