Update copier template

[jacob720]

Fixes #1807

Instructions to reviewer on how to test:

1. Check tests still pass
2. Check tox tools still work
3. Check uv works as intended

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.14%. Comparing base (993e1dc) to head (9aa2147).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1809   +/-   ##
=======================================
  Coverage   99.14%   99.14%           
=======================================
  Files         288      288           
  Lines       10957    10957           
=======================================
  Hits        10863    10863           
  Misses         94       94           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rtuck99]

Need to also update dev-install.md - remove the stuff that talks about pip.

Are we going down the route of devcontainers as the official recommended way?

[rtuck99]

Also should go through the docs and update all the places where it asks you to run tox and replace with uv run tox

[jacob720]

Have updated the docs, also gotten rid of uv run tox -e unit-report. uv run tox -e tests now only does unit tests.

Are we going down the route of devcontainers as the official recommended way?

This I'm not sure on, the docs make it sound like it's an option but not essential

[rtuck99]

Actually I think I may have sent you on a bit of a wild goose chase - I think actually you only need uv run if the dev environment isn't activated, therefore uv run isn't strictly needed.

[rtuck99]

is there a better way of doing this? I don't like to assume the location of the venv, since often I have multiple different venvs in the same project, both if working across multiple projects (think dodal and mx-bluesky at the same time) or if testing behaviour on different python versions.

[rtuck99]

Well, it seems like uv behaviour is very unexpected when your virtual environment is not installed in .venv, I got this cryptic message:

(.venv-uv) [yqf46943@ws502 mx-bluesky]$ uv sync
warning: `VIRTUAL_ENV=.venv-uv` does not match the project environment path `.venv` and will be ignored; use `--active` to target the active environment instead

astral-sh/uv#6612

lovely comment

It seems kind of wild to not respect VIRTUAL_ENV, for any command honestly. I'm not sure I can imagine a drawback. in the happy path, no one is setting it, or otherwise activating the virtualenv. but in every other case, it's the path of least surprise to me.

seems like there is a workaround

astral-sh/uv#6834

[tpoliaw]

Setting runner = "uv-venv-lock-runner" seems to work without the --pythonpath being set. @coretl was there a reason for using the python path when converting the copier template to uv?

As a side note, using uv is quick enough that it removes much if not all the need for creating multiple environments.

[rtuck99]

@tpoliaw what is the workflow when you edit two projects in the same env?

[tpoliaw]

To run something I use uv run --with /path/to/other/project ...

To make the editor LSP stuff work, I'd use uv pip install -e /path/to/other project

[rtuck99]

It does rather depend though on you being in the right directory, otherwise it is liable to find the wrong .venv
Either that or I have to set UV_PROJECT_ENVIRONMENT.
Perhaps we should consider for mx-bluesky moving the .venv up one level. Although that would create its own problems as at least on my workstation all the projects are at that level so it would require rearranging the project hierarchy

[jacob720]

Have changed that command so that by default it still use ./venv/bin/python, but you can override it like this

tox -e type-checking -- /path/to/python

Should I add this option to all tox commands?
Also could use the UV_PROJECT_ENVIRONMENT if you think that's better.

[coretl]

This was added here:
DiamondLightSource/python-copier-template@73c31e3

The test case that was added was broken initially, and fixed by adding --pythonpath. If the test in the copier template works without --pythonpath because of an updated pyright then happy to see it removed

[coretl]

There was a bug in that, please can you see if DiamondLightSource/python-copier-template#320 fixes this for you? If so I can make a new copier template release

[rtuck99]

Think everything is working now, have pushed a change for pyright virtualenv as suggested by @coretl if that works then I think this is now good.

In terms of developer workflow, I am currently trialling this plus the mx-bluesky change in pycharm with a single uv workspace across mx-bluesky and a bunch of dependencies. Will see how that goes