Use same uv workspace for django-stubs-ext also

[intgr]

Previously, both the top-level project and the ext subdirectory had their own .venv, their own uv.lock (although ext/uv.lock was never committed to git).

With a shared workspace, these now only exist at the top level.

Also, for the release workflow, the top-level dist/ output directory is now shared -- no more ext/dist/.

[intgr]

• Oops -- this was omitted in the previous PR Switch to uv_build build system & cleanup #2848

[UnknownPlatypus]

no worries, they behave the same anyway

[intgr]

Top-level dist/ directory is now used for both packages.

[UnknownPlatypus]

how does it look inside ?

Is there a risk we upload part of django-stub-ext in django-stubs or the other way around ?

And does it mean that a bare uv publish will publish both ?

[intgr]

Is there a risk we upload part of django-stub-ext in django-stubs or the other way around ?

Not as long as uv build respects the --package= switch. It only creates package files for one or the other package, not both.

And does it mean that a bare uv publish will publish both ?

Seems like it just looks at the dist/ directory and uploads whatever is present.

% uv publish --dry-run
error: No files found to publish

% uv build --package=django-stubs
...
Successfully built dist/django_stubs-5.2.5.tar.gz
Successfully built dist/django_stubs-5.2.5-py3-none-any.whl
% uv publish --dry-run
Checking 2 files against https://upload.pypi.org/legacy/
Enter username ('__token__' if using a token): ^C

% uv build --package=django-stubs-ext
...
Successfully built dist/django_stubs_ext-5.2.5.tar.gz
Successfully built dist/django_stubs_ext-5.2.5-py3-none-any.whl
% uv publish --dry-run
Checking 4 files against https://upload.pypi.org/legacy/
Enter username ('__token__' if using a token): ^C

[intgr]

how does it look inside ?

After running both build commands it has 4 files:

django_stubs-5.2.5-py3-none-any.whl
django_stubs-5.2.5.tar.gz
django_stubs_ext-5.2.5-py3-none-any.whl
django_stubs_ext-5.2.5.tar.gz

[UnknownPlatypus]

Then I suppose a simple uv publish might be enough here, I'm using this action for one of my packages ?

We can probably test with test pypi uv publish --publish-url https://test.pypi.org/legacy/

[intgr]

I suppose a simple uv publish might be enough here

We don't use manually configured PyPI credentials like the one linked above. There's some authentication magic that happens between GitHub Actions and PyPI.

No idea how it works, I'd rather not touch it myself. :)

[UnknownPlatypus]

There's some authentication magic that happens between GitHub Actions and PyPI.

oh right, that's probably good to keep indeed

[intgr]

In theory, we could use uv build --all here and publish in one GitHub job.

But I couldn't figure out whether pypa/gh-action-pypi-publish supports atomic uploads for multiple different packages.

So the original concern for splitting GitHub jobs may be still valid. --> #2183 (comment)

A problem that then shows up is that if e.g. django-stubs-ext succeeds but django-stubs fails, it's not possible to rerun the release action.

[sobolevn]

I think one job is even better: because now the first one can finish and the second one can fail.

[sobolevn]

I like the idea! Let's switch the release action as well :)

[sobolevn]

or not :)
because there are different envs and pypi config is not that simple, let's leave it as-is with two jobs for now. sorry!

[intgr]

Once we merge this, I will make an "alpha" release to verify that I haven't broken the release workflow.

If it succeeds, I'll create a stable release as well.