Move to uv and pin versions

[derkweijers]

Summary

Currently versions are not pinned in the project. This can lead to unexpected behavior when various people are working on the project at the same time, as versions of packages might differ based on when the project was cloned.

uv is gaining popularity quickly, it is extremely fast and is able to lock dependencies in a file called uv.lock. By locking the dependencies. This will result in a reproducable environment across various systems. It also reduces the chance of someone accidentally using a major new version of a dependency.

Motive

Generally speaking, it's best practice to provide version constraints on dependencies that are used in a project. This way, you prevent accidental major version bumps and introducing irregular behavior between systems. It also makes it possible to update packages in a controlled, automatic and predictable way with tools like Dependabot and Renovate.

At the same time, this will also enable the optimization of the Dockerfile, decreasing the size and speeding up the build time.

Implementation

pyproject.toml was updated with version ranges that should currently be supported by Mesa. This also generated a uv.lock which holds the exact versions.

Usage Examples

uv sync -> generate a virtual environment
uv run <some tool> -> run a tool/script within the virtual environment
uv add -> add a dependency to the project
uv add --optional <extra> <dependency> -> add a dependency to one of the extra groups

Many more options, as described in the docs

Additional Notes

• The project is still compatible with pip for people who are not using uv yet.
• If accepted/merged, the Dockerfile and workflows could be updated to use uv/uv.lock as well
• The docs of uv are located here: https://docs.astral.sh/uv/

[jackiekazil]

@derkweijers it seems that @hussainsultan added uv.lock in #2785, but also dependent on resolution is #2788.
I am thinking the best way to is remove uv in this PR? Let me know your thoughts.

[derkweijers]

@derkweijers it seems that @hussainsultan added uv.lock in #2785, but also dependent on resolution is #2788. I am thinking the best way to is remove uv in this PR? Let me know your thoughts.

Ah I see. I was still going through PRs, that's why this one was is/was still in draft.

This PR also adds version constraints, so you don't accidentally introduce a major update of one of the projects dependencies. A recept example could be Numpy which went from version 1 to 2 and introduced breaking changes. Adding version constraints prevent accidentally bumping to the next major version.

As for uv.lock conflicts; often a quick uv lock fixes this. As dependencies were added in #2785 a new lock file was created. Merging the PR and running uv lock creates a new lock file and all is good.

There's still a test failing. I'm heading into New York for the day so I'll take a look at it later. I'll just keep the PR on draft until all tests are green.

[jackiekazil]

Thank you. And thank you for your contribution and for coaching others. Have fun on your NYC adventure.
Let me know if there is anything I can do to help wrap this up.

[derkweijers]

Found the issue, I've introduced 2 small bugs when fixing Ruff findings in the example repo. Apologies!

Fixed in the this PR: projectmesa/mesa-examples#278.
Once merge, I'll trigger the actions for this PR again so it can be reviewed.

[EwoutH]

Move to uv is great!

What’s the maintenance/update plan/strategy for the fixed dependencies?

[jackiekazil]

@EwoutH periodic update?
@derkweijers - do you have another suggestion?

[derkweijers]

Apologies for the delayed response. I was traveling back home and spending some time with the family.

Personally I've been using Dependabot over the past few years. Uv support has been slow, so for my own projects I'm migrating to Renovate which does the same thing.

Both projects will update dependencies, lockfiles, GitHub Actions. Renovate is also able to update base images that are specified in Dockerfiles.

In my opinion if this PR gets adopted/merged, setting up Dependabot or Renovate would be one of the next steps.