add uv for running python?

[balhoff]

Should we include uv in ODK?

[matentzn]

I am in favour as well - we are leaving the other build systems behind now..

[gouttegd]

I am not sure what the point of adding uv within the ODK image would be.

I know one aim of the ODK is to provide “all the tools needed to work with ontologies (and that are too complicated for people to install manually)”, but including uv seems a bit too far.

The only reason would be if someone needs to either compile their own Python module and/or install additional Python packages (not already provided by the ODK) as part of a custom ODK workflow, but frankly if you already have this kind of complicated custom workflows, you might as well add a preliminary step to download uv.

Not completely opposed to adding uv, but not if the rationale is “just in case someone might need it”. Show me a concrete custom workflow currently in use where having uv available in ODKFull would make a difference.

[balhoff]

Sorry it was kind of a terse request. I came across the support for running fully standalone python scripts, where the dependencies and python version are declared in the header of the script. I love this idea and it might make python more palatable for me after being able to do this in scala for years. So I'm not super experienced with uv yet, but have noticed a lot of the projects moving to it, and it seems so much more sensible than previous python tooling I've been subjected to. To summarize: it seemed like it would be convenient to run standalone python scripts that have dependencies via uv.

[gouttegd]

So I'm not super experienced with uv yet, but have noticed a lot of the projects moving to it, and it seems so much more sensible than previous python tooling I've been subjected to.

Yes, uv is great to manage a Python project and to install Python packages, there is little doubt about that.

That does not mean that running any single Python script through uv is a sensible thing to do. In fact, in the context of the ODK, I think it is a very bad idea.

When you run a script with embedded dependency declarations with uv, uv will ignore whatever is in the system environment and create a dedicated new environment in which to install the dependencies required to run the script — even if all the dependencies were already present in the system!

So I have a script like this one for example:

# /// script
# requires-python = ">=3.12"
# dependencies = ["sssom"]
# ///

import sssom

print("Hello world!\n")

and I run with

$ uv run hello.py

uv will create a new environment in which it will install sssom (and all its 50+ dependencies), prior to running the script ­— despite the fact that in the ODK, sssom is already available in /usr/local/lib/python!

This may not be a problem outside of the ODK, when you run scripts on your local machine, because then the environment created for the script will be cached by uv so that the environment will be reused across invocations.

But in the context of the ODK, whatever uv will cache will not live for any longer than the ODK container in which uv is invoked. Therefore you will end up systematically creating a new environment and downloading all the dependencies of your script whenever you run a new ODK command. What’s even the point of having 1.5GB worth of Python packages in ODKFull then?