chore: add env file to support `uv`

[lkstrp]

Ref #1660

Changes proposed in this Pull Request

@stefan-oet something like this we could add next to #1660

# requirements.in file to be used with package managers like pip or uv and the
# equivialent to 'envs/environment.yaml' for conda. 
# The locked version of this file is in `envs/locks/requirements.txt` and can is 
# regularly updated.

# To create a environment with uv, run:
# uv venv # (create new environment)
# uv pip sync envs/locks/requirements.txt # (install dependencies from locked file)

# WARNING
# The PyPSA-Eur workflow depends on non-Python packages like glpk, which cannot be 
# installed via uv or pip. You need to install them separately if you want to use
# this requirements file. To get a environment with all needed dependencies installed, 
# use conda/mamba (see 'envs/environment.yaml')

Checklist

• [x] I tested my contribution locally and it works as intended.
• [ ] Add test based on uv environment
• [ ] Add to update pinned envs ci
• [ ] Code and workflow changes are sufficiently documented.
• [ ] A release note doc/release_notes.rst is added.

[lkstrp]

@FabianHofmann

and we don't need glpk anymore as we have highs :)

For me, this file works fine and all I need to do is install glpk. If glpk is not needed at all, that would be even better. But I have tons of stuff installed, so we need to check this on a fresh system as well.

I guess the main disadvantage of this PR is the double maintenance required for requirements.in and environment.yaml. But I think this is fine. It's up to each user to decide which package manager env they want to use then.

[coroa]

Could those deps move into a project.toml?

So that I can just do uv run snakemake?

[lkstrp]

@coroa

They could. I decided against it because a pyproject.toml implies that we have a package here, which PyPSA-Eur is not. But I don't have any hard feelings about that either. Specially if we really don't need any extra dependencies.

[coroa]

@coroa

They could. I decided against it because a pyproject.toml implies that we have a package here, which PyPSA-Eur is not. But I don't have any hard feelings about that either. Specially if we really don't need any extra dependencies.

I don't think that is true, pyproject.toml implying package (but unsure).

And I would like to make it into a package in the course of the modularization.

[stefan-oet]

pyproject.toml would definitely be nice to have even if we don't have a package yet.

In addition to future modularization, we could also already define different dependency groups (e.g. core vs development) which is nicer than having for example a separate -dev.txt file.

[lkstrp]

I'm convinced, let's go 🚀

It's also nice to be able to add other configurations. I'll adjust the PR

[coroa]

Any progress here? I am close to submitting a first PR for the data catalogue/sector modularization as a discussion basis and i'd want to also use a pyproject.toml there with pypsaeur package. If you set one up here, i'll reuse that; otherwise, i'll just come up with a quick own one.

[lkstrp]

Sorry, I haven't got to it yet. But go ahead — we can still merge your version via another pull request/ in here if the data catalogue one stays open for a while

[fneum]

No objections to merging this, but could we add this option to the documentation then (with a list of packages that need to installed by other means)?

Wondering where the GLPK dependency comes from. It should no longer be required.

[lkstrp]

I added a pyproject.toml file and a uv.lock file, as well as adding uv to the CI. It works like a charm. uv run .. works out of the box with no need for environment management.

I kicked GLPK, which also does not cause any issues. This means that we can install all dependencies via 'uv' and use it as a full alternative to Conda. Could you have a look and double-check, @coroa and @stefan-oet? If it works out of the box, we can update the docs and frame it as a full alternative (maybe better) to Conda. While keeping full Conda support. Or maybe we merge this first, play around with it and update the docs then.

Another thing to test is whether this also works with Slurm. But I can't see any reason why it shouldn't.

[fneum]

I tried locally and it also worked smoothly for me.

We keep conda support.

In the docs, perhaps add installation instructions with uv and mark as "experimental".

Someone does the test on HPC - we don't have to wait for this to merge.

[lkstrp]

I did an HPC test and it didn't work. So we need to mention that in the docs

[fneum]

@lkstrp, should we just get this on the way? We can mark it as experimental.

[lkstrp]

Yes! I just discussed it with @Irieo and was reving this. I only wanna wait for #1675 to include the new dependencies and have a stable CI

[lkstrp]

Closed in favour of #1886