Use uv/hatch instead of Poetry

[mquinnfd]

Tracking WIP towards replacing poetry with uv/Hatch (and maybe ditching tox at the same time)

[mquinnfd]

Just for visibility, I'm working from this draft PR here https://github.com/locustio/locust/pull/3039/files

• Poetry etc. switched to hatch/uv
• Dynamic versioning stuff working OK locally
• Local build with front end compilation working
• Started moving tox targets over to hatch envs
• Running existing tests via pytest (which was already added) plus coverage

Probably going to be next week before I tackle the pipeline, as this takes longer generally, but I'd say it's going well 🥳

[mquinnfd]

Ok the CI is fully green on this 🚀 💯
This is supposed to be a like-for-like, same logic applies with re-using the same build throughout the CI/CD process

Things done:

• poetry moved to uv/hatch
• tox moved to hatch test environments
• Dynamic versioning with hatch-vcs
• Existing tests now run with pytest
• Pre build runs as hatch hook
• Dockerfiles etc. updated
• ReadTheDocs config updated and build green

Things not done:

• Update documentation and Makefile
• Sand down rough edges on pipeline
• Add pipeline caching where possible
• Try and parallelise tests for fun
• Test release process (none of these steps changed though)
• Reinstate failing "date" tests

[cyberw]

Looks grand! Going through the code now!

[cyberw]

What was the reason to change this? (this is probably mostly @andrewbaldwin44 's area :)

[mquinnfd]

I'm gonna reinstate this --- it was originally breaking something but it's on my TODO listed here: #3039 (comment)

[cyberw]

setting version here is probably redundant.

[mquinnfd]

Yeah I believe this was maybe because the original CI is running under 3.11 at a basic level, if we don't specify, I think it will default to 3.12 ---

Whatever you wanna pick I'd just like to make sure that's the same everywhere that doesn't have a specific version required

[cyberw]

Shouldn't it default to the version installed by actions/setup-python (specified on line 38)?

If it does default to that then I prefer not specifying it again, as someone is bound to forget to update both places :)

[mquinnfd]

Yeah good shout, I'll start taking a note of these on the TODO

[cyberw]

Hmm... I just did uv sync and uv run locust locally but got this. Does it work for you?

❯ uv run locust
warning: No `requires-python` value found in the workspace. Defaulting to `>=3.11`.
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/lars/git/locust/locust/__main__.py", line 1, in <module>
    from .main import main
ImportError: attempted relative import with no known parent package

Activating the venv and running locust directly works fine.

❯ . .venv/bin/activate
❯ locust
Could not find 'locustfile.py'. Ensure your locustfile ends with '.py' or is a directory with locustfiles. See --help for available options.

[mquinnfd]

@cyberw yes - running locust as it is installed into the venv works fine

The reason uv run <stuff> doesn't is down to the relative paths used in the project, you'd need to run it from the locust directory to run it with uv run

For example, this works: uv --directory locust run locust

[mquinnfd]

I guess I still have @andrewbaldwin44 's comments about poetry run bouncing around my head - less of this stuff the better right (?)

[cyberw]

@cyberw yes - running locust as it is installed into the venv works fine

The reason uv run <stuff> doesn't is down to the relative paths used in the project, you'd need to run it from the locust directory to run it with uv run

For example, this works: uv --directory locust run locust

How come it worked for poetry? Can we fix how we use relative paths?

We've gotten some other semi-related complaints too: https://github.com/orgs/locustio/discussions/3040

[cyberw]

If I fix the issues with html.py (by temporarily modifying sys.path to not include locust), I can change the import in __main__.py to from locust.main import main. Maybe that is the appropriate solution? (and then later rename the html.py module)

[mquinnfd]

This is similar to what I do in my projects ---
Everything is imported from that root, in this case, the locust module. You might need to add the locust folder to the extra analysis paths in VS Code etc.
Imports are locust.blah.blah in all cases, no relative imports.

As you said, doing that just requires the package base (locust) to be on the Python path --- we can change this if you're up for it, was just going for like-for-like currently.

[mquinnfd]

Up to you, I could do this on a branch-of-this-branch and take a look at how it feels I guess, it's obviously a bigger, potentially breaking change

I'm not sure if poetry does some sneaky stuff with the path in it's "run this script" command, it's entirely possible 🤔

I was hoping the uv run command would have some sort of config-level override for directory, rather than a flag, but I can't really see it in the docs 🤔

[mquinnfd]

@cyberw yes - running locust as it is installed into the venv works fine
The reason uv run <stuff> doesn't is down to the relative paths used in the project, you'd need to run it from the locust directory to run it with uv run
For example, this works: uv --directory locust run locust

How come it worked for poetry? Can we fix how we use relative paths?

We've gotten some other semi-related complaints too: https://github.com/orgs/locustio/discussions/3040

This makes sense, maybe it would avoid this type of issue also, using absolute paths

[cyberw]

If I fix the issues with html.py (by temporarily modifying sys.path to not include locust), I can change the import in main.py to from locust.main import main. Maybe that is the appropriate solution? (and then later rename the html.py module)

I will fix that, once this PR has been merged (if this is enough, I prefer not making a bigger change)

[mquinnfd]

Hey @cyberw this should be good for a review.
I reintroduced caching, updated the docs to remove poetry and tox steps, cleaned up the Makefile etc. as well.

Couple things

• Docs steps could be subjective? If they're unclear happy to change
• I left this in currently from your original helpful paste, I'm not sure if we need it 🤔 and I'm not sure what scenario to use to test this
• I don't think this should affect the publishing step at all

It's shaving 2-3 mins off the e2e CI runs as well which is nice 🥳 new vs old

[cyberw]

I guess there's no direct equivalent, that runs all versions in one invocation?

[mquinnfd]

Technically we should be able to wrap it up in hatch test re: this

Originally this seemed to just break when collecting tests with pytest - hatch test just appears to be a way of calling pytest specifically

I'll mess around with it and see if I can get it to work

[cyberw]

Does it really make sense to add -vv everywhere?

[mquinnfd]

Not necessary 👍 it's just a tad easier to see what specific tests are breaking during execution, can just omit this by default

[cyberw]

Awesome! Apart from those two nit-picks, I think we're good to go!

Docs steps could be subjective? If they're unclear happy to change

Sorry, I dont quite follow? Anyway, I didn't see anything that looked terrible :) And docs are easy to fix "later"...

[mquinnfd]

Awesome! Apart from those two nit-picks, I think we're good to go!

Docs steps could be subjective? If they're unclear happy to change

Sorry, I dont quite follow? Anyway, I didn't see anything that looked terrible :) And docs are easy to fix "later"...

Nothing in particular 🥳
Documentation anxiety 😆

[mquinnfd]

Updated this again, I've layered some of the hatch environments a bit to leverage the default "hatch test" environment

The result is that:

• contributors can just call hatch test locally (and make use of the CLI options this wraps)
• the CI targets will still run hatch run test:all because this allows us to keep the matrix option there rather than mixing multiple CLI calls

[cyberw]

Looking real good! In your perspective, is it good enough to merge?

Let me know a time that works for you (I know the builds are working on your branch, but only merging to master will tell us for sure that the pypi/docker upload still works and gets the right versions :)

[mquinnfd]

Looking real good! In your perspective, is it good enough to merge?

Let me know a time that works for you (I know the builds are working on your branch, but only merging to master will tell us for sure that the pypi/docker upload still works and gets the right versions :)

I'm with you, this is everything obvious I can think of, it just needs ironed out in prerelease now

I'll be around here and there at the weekend, but I can set aside time on Monday to play whack-a-mole if that works?

[cyberw]

I'll be around here and there at the weekend, but I can set aside time on Monday to play whack-a-mole if that works?

Monday sounds great!

[cyberw]

I keep getting this warning:

warning: No `requires-python` value found in the workspace. Defaulting to `>=3.13`.

Probably we just need to add requires-python = ">=3.9" to [project]

[mquinnfd]

I keep getting this warning:

warning: No `requires-python` value found in the workspace. Defaulting to `>=3.13`.

Probably we just need to add requires-python = ">=3.9" to [project]

Yeah I think that's it, I'll stick that in the config.
I'm around whenever today btw 👋

[cyberw]

Cool! I’ll hit merge in about 5 minutes :)