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

Release mono-repo requiring sub-package released version #371

Open
davidbrochart opened this issue Sep 2, 2022 · 10 comments · May be fixed by #372
Open

Release mono-repo requiring sub-package released version #371

davidbrochart opened this issue Sep 2, 2022 · 10 comments · May be fixed by #372
Labels
enhancement New feature or request

Comments

@davidbrochart
Copy link
Contributor

Problem

Jupyverse is a Python mono-repo consisting of a "main" jupyverse package and a bunch of "sub-packages" in plugins (fps-contents, fps-kernels, etc.).
When releasing e.g. 0.1.0, I would like jupyverse to depend on sub-packages with version ==0.1.0 too. But I cannot pin them in setup.cfg, because at the time of release these sub-packages would not have been released yet.
Maybe I'm missing something?

@davidbrochart davidbrochart added the enhancement New feature or request label Sep 2, 2022
@blink1073
Copy link
Contributor

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

@davidbrochart
Copy link
Contributor Author

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.

@blink1073
Copy link
Contributor

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.

@davidbrochart
Copy link
Contributor Author

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

@blink1073
Copy link
Contributor

Interesting idea, a release manifest file.

@davidbrochart
Copy link
Contributor Author

davidbrochart commented Sep 2, 2022

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.

@blink1073
Copy link
Contributor

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.

@blink1073
Copy link
Contributor

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

@davidbrochart
Copy link
Contributor Author

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

@blink1073
Copy link
Contributor

You too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants