Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move from venvstarter to only using uv #60

Merged
merged 5 commits into from
Sep 19, 2024
Merged

Move from venvstarter to only using uv #60

merged 5 commits into from
Sep 19, 2024

Conversation

delfick
Copy link
Owner

@delfick delfick commented Sep 15, 2024

All of my own projects use a project I started in 2016 to manage the virtualenv and dependencies in the project.

It came from the basic premise that I should be able to do nothing more than clone the repo and ./test.sh or ./my_program to be able to bootstrap the project and use it.

One of the problems I've always had with venvstarter (other than it's a niche tool that only I use and maintain) is that I can't have a lock file with it. And now it's kinda difficult to make it use uv. I started to rewrite venvstarter itself but I've decided perhaps I can have what I want with using uv itself and not having my software in the middle.

Turns out that's possible and this PR does just that to this project.

There's some awkward stuff cause I'm supporting multiple versions of mypy/django-stubs and uv project stuff doesn't have the capacity atm for conflicting requirements.

Though having said that with this change it becomes much easier to be able to run those tests locally and CI without having to apply a patch to the codebase (also because I did a change so that a patch isn't required for turning the proper_plugin on and off).

Ultimately I'm able to keep my variant of the scripts to rule them all pattern and have root level ./dev, ./lint, ./format, ./types and implement this with uv and click instead of with venvstarter.

And I rely on uv sync to bootstrap the virtualenv as well as now have a lock file.

@delfick delfick force-pushed the venvstarter-upgrade branch 16 times, most recently from afc808d to 78cc4e1 Compare September 16, 2024 01:20
The problem I have is that the proper_plugin is really useful but not
available in the older mypy, and so when testing with an older mypy
version I can't have the plugin enabled cause in that scenario it
doesn't exist.

So instead I make it so there is a plugin that always exists, but is a
no-op when the proper_plugin functionality doesn't exist
This means the project can be very specific about what uv version is
being used.

We use pip to get the version we want as this is cross platform and
doesn't require running bash on code curl'd from the internet
@delfick delfick force-pushed the venvstarter-upgrade branch 2 times, most recently from 07b3f8d to 0e6603b Compare September 16, 2024 01:42
tools/_sphinx_autobuild.py Outdated Show resolved Hide resolved
@delfick delfick marked this pull request as ready for review September 19, 2024 01:20
@delfick delfick merged commit b1162de into main Sep 19, 2024
14 checks passed
@delfick delfick deleted the venvstarter-upgrade branch September 19, 2024 01:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant