freeze dso version in in projects

[grst]

I would like to tie a certain dso version to each project for reproducibility. 

Proposed solution: 

specify the dso version and dso-r version in the params.in.yaml at the project root. e.g. dso.versions.dso, dso.versions.dso-r when running dso on a project, or dso-r, and the version doesn't match, it produces a hard failure with a corresponding error message to update dso. 

Additionally, there will be a separate package, e.g. dsowrapper that installs another dso binary that can manage multiple dso versions using pipx. It replaces the dso binary and redirects to a versioned binary. 

This ensures maximum flexibility: A user can choose to work with standard dso and e.g. have project-specific virtual environment with the appropriate version installed. They can also decide to have the versions managed via dsowrapper if they prefer. 

In any case, failing on a different version should guarantee that the project is reproducible. 

[grst]

uv tool run is probably even better (faster) than pipx: https://docs.astral.sh/uv/guides/tools/

[grst]

specify the dso version and dso-r version in the params.in.yaml at the project root. e.g. dso.versions.dso, dso.versions.dso-r

We should instead have lock files that freeze the entire environment. Specifying the dso version might not be enough, e.g. when hiyapyco would get updated and changed behavior.

[grst]

I've been playing a bit more with uv and I think this is a good solution to move forward.

suggested implementation

• every dso project becomes a uv project at the same time (by adding pyproject.toml). Within the pyproject.toml one can declare the python dependencies used by the project. By default, this would only be dso_core. If the user wants, they can add additional python dependencies there to be used by their analysis scripts (if they like to work with a "one-venv-per-project" approach).
• When inside a dso project, use the command uv run -- dso "$@" to execute dso commands. In this case, uv will automatically create a uv.lock file that freezes all package versions used, ensuring reproducibility across different environments.
• When outside a dso project (e.g. to run init), use the command uv tool run --from dso_core -- dso --version, or a globally installed dso binary (uv tool install --from dso_core dso).

Like that, different versions can be used within and outside a dso project.

To upgrade the dso version in a project, the user can run either

uv lock --upgrade-package dso_core

or, to add it as a requirement to pyproject.toml

uv add "dso_core>=0.9"

Open questions

Obviously the commands above need to be wrapped somehow. One does not want to type uv tool <somethign> every time for a command used as frequently as above.

We also want to respect users that don't want to or cannot have their environments automatically managed (e.g. due to restrictions imposed by administrators, or when working in airgapped environments).

Option 1: dedicated dso-manager script/package.

Instead of installing dso_core globally, we install a simple wrapper script that looks somewhat like this:

if within_dso_project:
   run(["uv", "run", "--", "dso", *argv[1:]])
else:
  run(["uv", "tool", "run", "--from", "dso-core", "dso", *arvg[1:]])

If a user doesn't want to use uv to manage their environment, they can just install dso_core globally and work with a single version. In such a case we would not provide any gurantee on their projects being reproducible, they would be on their own to ensure that (which is fair).

Advantage:

• clear separation of version management logic and "dso logic"
• could be easy to bootstrap. All the user needs is uv and download a plain script they can copy into a bin directory.

Disadvantage:

• can be confusing what to install as the dso_core package is also still installable via pip
  • maybe less of an issue if we rename the binary provided by dso_core from dso into dso_core.

Option 2: uv logic integrated into the dso command

One always installs dso_core globally. However, when running any project-related dso command within a dso project, it executes uv tool run internally:

@click.command("compile-config")
def cli(args):
   if within_project and not os.environ["DSO_NO_UV"]:
     run(["uv", "tool", "run", ..., *args])
   else:
     compile_config()

If a user doesn't want to use uv to manage their environment, they can set the DSO_NO_UV environment variable.

Advantages:

• one obvious way to install via pip

Disadvantages:

• possibly a bit obscure what happens

other options (?)

There might be other ways, let me know if you have another idea.

[grst]

There's a preliminary version of dso-mgr available. The dso project template has been adapted in #52 such that uv can be used to specify the dso version in a project.

This needs some more testing before rolling this out and it's fully backwards-compatible (i.e. only projects using the new template will be affected).

[grst]

Closing in favor of https://github.com/Boehringer-Ingelheim/dso-mgr/issues/3