feat(uv): add uv as a pip alternative for dealing with pypi

[KingMichaelPark]

UV is a very fast installer for python packages
that can be 10-100x faster to resolve packages. This adds
an option for Mason to use it instead of pip to resolve
python packages that are installed via Mason.

More info about the replacement: https://github.com/astral-sh/uv
I have no affiliations with uv/astral, it is just very fast and
it would be nice to have updates for packages like sqlfluff take
a lot less time than they currently do to resolve during updates.

[iguanacucumber]

I think we should do this for bun too, since now it's compatible with alot more things now

[PyDataBlog]

Can we get some traction for this? it would boost pkg installation speeds astronomically.

[iguanacucumber]

i tried installing about 10 python based tools with this PR:

• with pip -> 2 minutes
• with uv -> 15 seconds

[iguanacucumber]

i'm having some issues on another computer:

[KingMichaelPark]

@iguanacucumber if you could retry it seems to be resolved on my side now

[iguanacucumber]

every other package installs file excepts debugpy

[KingMichaelPark]

I won't have time to work on this for a few days so you're more than welcome to open a PR on my branch if you desperately need it. (You should be able to just add debugpy to your dev dependencies in your project as a workaround in the short term)

[KingMichaelPark]

Alright, debugpy installs now, to have this work with mason-lspconfig I had to fork that for now:

return {
    "neovim/nvim-lspconfig",
    dependencies = {
        { "KingMichaelPark/mason.nvim", opts = { pip = { use_uv = true } } },
        "KingMichaelPark/mason-lspconfig.nvim",
        "hrsh7th/cmp-nvim-lsp",
        "nvim-telescope/telescope.nvim"
    },

[lljbash]

This PR is really helpful! I was wondering if the maintainer has any plans to merge it? @williamboman

[dusktreader]

Not only would this boost install speeds dramatically for lsps that are installed via pip, it would also eliminate the need for pip itself and consequently for python3-venv.

Further, the packages could require different versions of python since uv can install python binaries as well. I believe this happens automatically.

[user520881]

is there plans to merge this?

[Xylot]

@williamboman Are there plans to merge this?

For anyone that needs a quick workaround, I noticed that Mason appends itself to the top of the path at nvim startup:

:echo $PATH
>>> ~/.local/share/nvim/mason/bin:...

So I just symlinked my system python to that directory in order to force Mason to recognize it first.

ln -s /usr/bin/python3 ~/.local/share/nvim/mason/bin/python3

[KingMichaelPark]

Quick question: Does this also appear in checkhealth? Cuz imo it should but marked as optional

Now it does.

[KingMichaelPark]

@williamboman @seblyng @mirekdlugosz This also fixes the 404 in your CI for shellharden.

[gaardhus]

What is holding this PR back? Looking forward to being able to use uv with mason.

[benatouba]

It would be amazing to see this merged.

[iguanacucumber]

Been rocking this branch for a year now (previous message) and i've encountered no issues for months, its pretty stable.

[KingMichaelPark]

(Rebased to latest)

[Mintass]

Anything left before being merged? I'm currently using uv as a replacement for pip, really excited for this PR.

[Conarius]

It now only needs approval from @williamboman

[acsezen]

Any reason to not approve it? @williamboman
Thanks!

[lljbash]

Found a bug: commit aa279cb lost most of the use_uv logic. When use_uv = true, the code still uses python3 -m venv instead of uv venv, causing installation to fail on systems without python3-venv.

Fix: KingMichaelPark#2

I used vibe coding (AI-assisted) to debug and fix this. Please review carefully before merging.

[mrijken]

What is need to get this merged?

[williamboman]

Hey guys apologies for not attending to this for over 2 years (I was going for a world record). I saw this when it was first opened but I haven't been too interested in adding this for the following reasons:

1. uv was fairly new at the creation of this PR, this is definitely not the case anymore as it's managed to become quite dominant within the python community
2. mason uses a lot of different tools, which people have many opinions of. when bun was released people instantly requested bun support (without actually realizing what it would entail). supporting a variety of different toolchains for a package source is a non goal
3. the only compelling argument I can think of to add uv support would be to alleviate the requirement on python3-venv which for some reason is not included in certain distributions, specifically Debian. faster installs are certainly a big bonus but in my mind not enough to justify the added complexity (different virtualenv implementations and saturating mason settings with more options)

As for the implementation itself, I'd want to avoid the branching that's happening and instead implement uv as a standalone "compiler". I wouldn't be opposed to a different solution where mason doesn't necessarily lock itself into permanently supporting both python3-venv and uv through the concept of simple feature flags, i.e. to enable uv:

require("mason").setup {
  features = {
    "python-uv"
  }
}

Does this sound like an acceptable solution to you guys? Also, do you agree with my 3rd point above or am I missing something in terms of what supporting uv would offer?

[KingMichaelPark]

Hi @williamboman that makes perfect sense to me. You're under no obligation to support things you don't want to maintain (or in this case the way it has been implemented). If you wanted to close this in favour of implementing something more generic I think that makes sense. (I've just been mainting the fork for this PR for a while and there's been no issue with me rebasing from time to time).

The only way I could see your maintanance burden becoming easier would be allowing users to override the install, update, uninstall command at their own risk. (just having your current maintainable behaviour the default). Something along the lines of (warning just pseudo code):

local settings = {
    overrides = {
        pypi = {
            uninstall = function(pkg) return { "uv", "pip", "uninstall", "--color", "never", "--directory", "venv", pkg } end,
            install = function(pkg) return { "uv", "pip", "install", "--color", "never", "--directory", "venv", pkg } end,
            upgrade = function(pkg) return { "uv", "pip", "install", "-U", "--color", "never", "--directory", "venv", pkg } end,
        },
    }
}

function M.uninstall(pkg)
    log.fmt_debug("pypi: uninstall %s", pkg)
    -- The ability for others to override (maybe you need to tell them what the directory needs to be though)
    local override = settings.overrides.pypi
    if type(override) == "table" and type(override.uninstall) == "function" then
        return override.uninstall(pkg)
        -- Your existing code
    else
        return venv_python {
            "-m",
            "pip",
            "uninstall",
            "-y",
            pkg,
        }
    end
end

I am not sure if this is any better for you, but it might solve the bun/pnpm issues as well if you just let users use alternative tools with a little guidance on where to specify packages to be installed. But I did not spend a tremendous amount of time looking through the code so I don't know if just knowing that is sufficient to making the tools executable or not, so this might be a bad idea.

Regardless, whatever you want to do is fine, it won't really affect me much!

[williamboman]

Something like that is already possible, although technically not a public API yet (haven't fully tested this yet but it should work).

local Result = require "mason-core.result"
local path = require "mason-core.path"
local compiler = require "mason-core.installer.compiler"
local pypi = require "mason-core.installer.compiler.compilers.pypi"

local extend = { __index = pypi }

local uv = {
    ---@async
    ---@param ctx InstallContext
    ---@param source ParsedPypiSource
    install = function(ctx, source)
        -- Note that this implementation will always try to use uv and not fall back to default.
        -- Uncomment the following for a default fallback.
        -- if vim.fn.executable "uv" ~= 1 then
        --   return pypi.install(ctx, source)
        -- end
        return Result.try(function(try)
            ctx:promote_cwd()
            try(ctx.spawn.uv({ "venv", "venv" }))
            try(ctx.spawn.uv({
                "pip",
                "install",
                source.extra and ("%s[%s]==%s"):format(source.package, source.extra, source.version)
                or ("%s==%s"):format(source.package, source.version),
                source.extra_packages or vim.NIL,
                env = {
                    VIRTUAL_ENV = path.concat { ctx.cwd:get(), "venv" },
                },
            }))
        end)
    end,
}

setmetatable(uv, extend)

compiler.register_compiler("pypi", uv)

[KingMichaelPark]

Do you have a preference one way or another on whether you want this to be added to mason and if so, do you want the community to do it or is it something you'd prefer to implement in the future? (I couldn't tell by your response, but I certainly appreciate you sending the snippet above!)