chore: use uv to manage venv

[tobiasdiez]

Use uv in the readme (and to build the docs), instead of plain pip.

Also change the build backend to uv (since its a bit faster, and still actively maintained which you cannot really say about setuptools).

Background: If I understood Tonn correctly (to be double-checked tomorrow), then uv is the easiest way to create a reproducible venv on the cluster. But independently of the use case, uv is the modern replacement of pip.

[JakobBD]

Thanks for the upgrade!
I'm happy to switch to a cleaner workflow.
We haven't worked wit uv lock files so far, but not for very good reasons, so I'm happy to add them.

It may be good for us to have a short intro to uv workflows, either written or orally. If you write it down, I think REMIND-MFA is the best place rather than flodym. I'm sure, there's also existing tutorials online? Should just be short and limited to the bits we need regularly.
We've obviously worked with it before, but I have some questions on standard practices (and on VSCode integration in particular), and I'm certain the others do as well.

As for the editable flodym: It has eased our workflow in the past to have it editable by default, and we were the only REMIND-MFA users. I see, of course, that this changes soon, so it's only a matter of time until we have to change it. So I'm also okay with doing it now.

[tobiasdiez]

It may be good for us to have a short intro to uv workflows, either written or orally. If you write it down, I think REMIND-MFA is the best place rather than flodym. I'm sure, there's also existing tutorials online? Should just be short and limited to the bits we need regularly. We've obviously worked with it before, but I have some questions on standard practices (and on VSCode integration in particular), and I'm certain the others do as well.

I searched a bit online, and was surprised that I couldn't find a good general guide that focuses on the basics of using uv to setup a venv and running commands. As probably more people would be profiting from such a guide, I've added one in scientific-python/cookie#829 to the scientific python website. Rendered version can be found at https://scientific-python-cookie--829.org.readthedocs.build/en/829/guides/uv/. If you have any suggestions, please add them either here or in that PR (or tell me in our next call).

As for the editable flodym: It has eased our workflow in the past to have it editable by default, and we were the only REMIND-MFA users. I see, of course, that this changes soon, so it's only a matter of time until we have to change it. So I'm also okay with doing it now.

Sadly, I don't have a good solution for this at the moment. There are a couple of open issues in uv, some with partial workarounds, eg astral-sh/uv#7945 and astral-sh/uv#9258 (comment). In my limited testing, it sufficed to uncomment the line once, then run uv sync, then restore the pyproject.toml. Further usages of uv run kept using the editable install of flodym. That was good enough for me so far.

[JakobBD]

Thanks for the tutorial!
Only thing "missing" from my point of view would be how to integrate that with VSCode (debugger and tests), though this tutorial is probably not the right place for that.

As I said, let's try this solution with the editable flodym. If it's too much of an annoyance in our daily workflow (I don't think it will be), we can still go the dirty way and uncomment the respective lines by default.

[tobiasdiez]

Thanks for the tutorial! Only thing "missing" from my point of view would be how to integrate that with VSCode (debugger and tests), though this tutorial is probably not the right place for that.

Thanks for the feedback. For vscode, it should correctly discover everything after you run uv sync.

As I said, let's try this solution with the editable flodym. If it's too much of an annoyance in our daily workflow (I don't think it will be), we can still go the dirty way and uncomment the respective lines by default.

👍