Right now we are releasing the files in alphabetical order. We could inspect the dist files' dependencies and release them in dependent order.

Yes, but I would still need to make a commit with the sub-package pinning that wouldn't pass the tests, because they would not have been released yet.

Right, for the commit that updates the versions. I don't see a way around that unless you make a local file that has the next version mapping and the have the version bump use that during release.

That would work. The release order could also come from this file.

Interesting idea, a release manifest file.

Couldn't we just make the python_packages option play that role? Since it's a list, we could respect the order when releasing, and add dependencies.
For instance (I reduced the number of sub-packages):

python_packages = [
    "plugins/auth:fps-auth",
    "plugins/contents:fps-contents",
    ".:jupyverse:fps-auth,fps-contents"
]

Means jupyverse needs the "just-released" versions of fps-auth and fps-contents.
But that means the releaser must change jupyverse's setup.cfg or whatever file its dependencies are listed in, to add the pinning.

Oooh, I like the idea of using that for the order. I'd suggest upgrading to pyproject.toml and adding a general capability to update versions using a manifest file. You can use hatch new --init to automatically convert to hatch.

If you want to stick with setuptools, you can use https://github.com/abravalheri/ini2toml

Thanks, I'll look at that next week, have a great week-end Steve!

You too!