Release antsibull 1.0.0 without antsibull-lint

[felixfontein]

Right now, antsibull depends on antsibull-changelog. The dependency is needed for antsibull-lint and antsibull-build, but not for antsibull-docs. If antsibull bumps its antsibull-changelog dependency, and we want to update antsibull in the ansible docs build, we also have to bump the antsibull-changelog version of the changelog sanity test. (See ansible/ansible#77362 for an example.)

This in turn requires that not only the default container for ansible-core is rebuilt, but also the default container for collections, and that changes to the docs build have visible consequences in the ansible-core installations.

This is something that was annoying in the past, and something I really would like to stop. What isn't obvious though is how to do this. I'd like to use this issue to explore ways of how to do this.

1. Which/how many packages?

   a) There needs to be one antsibull-docs package (containing the antsibull-docs CLI program) and one antsibull package at least (if just for backwards compatibility, if all code is moved out of it).
   b) We could also have packages antsibull-core (shared code), antsibull-lint (containing the antsibull-lint CLI program), and antsibull-build (containg the antsibull-build CLI program)/

2. Can we get rid of antsibull-lint? Right now that tool needs both code from antsibull-docs and from antsibull-changelog. We could deprecate it and move its collection docs validation functionality to a new subcommand of antsibull-docs, and its changelog.yaml validation functionality to a new subcommand of antsibull-changelog. Then we can eventually remove antsibull-lint completely.

3. How should these packages interact? One could simply lock their versions to each other, i.e. they all have a common version number, and if one of these packages depends on another, they have a == version specifier for that dependency. This would simplify development. On the other hand, more flexibility would be nice - especially if antsibull-lint is gone and there's just some shared code that's actually shared.

4. A monorepo to contain them all, or different repositories? I think this mainly depends on 3; if versions are locked, having everything in one repository is the easiest way to go. If the versions are not locked, different repos would be better to allow independent releasing.

[briantist]

If 3 (version-locking), doesn't that negate much of the benefits of splitting in the first place? Or am I missing something?

For 2, I think what you propose makes sense, removing -lint and adding sub-commands for specific areas.

I otherwise think splitting makes sense, but I can't really say about having core, or how exactly the split them. I just don't have enough experience/context with them as a user or developer to say for sure.
Same for monorepo vs. separate.

[felixfontein]

Version-locking shouldn't be a problem, as long as ansible/ansible's tests only use antsibull-changelog (which is a separate project) and antsibull-docs. But in general it could become a problem eventually. Of course the version locking can be relatex / undone later on.

[felixfontein]

There are new antsibull-changelog and antsibull releases which provide new subcommands for the antsibull-lint functionality (as described above). I've also announced that antsibull-lint will be deprecated, and #412 implements that. So this part will definitely happen. The remainder still has to be discussed :)

[felixfontein]

I created a WIP PR: #414 It right now only includes the antsibull-changelog repository as a poetry path dependency and shows how that would look like. For users nothing will change, but developers need to check out more repositories and keep them in the correct structure relative to each other.

I also created new repositories https://github.com/ansible-community/antsibull-core and https://github.com/ansible-community/antsibull-docs.

[felixfontein]

The repositories are filled with a first attempt of splitting this up. I'll publish them to PyPi later today. My idea is to work on this a bit more, maybe shuffle some more code, and then release antsibull-core and antsibull-docs with version 1.0.0 each and declare them stable. The code has been stable for a longer time anyway.

[felixfontein]

antsibull-core 1.0.0 and antsibull-docs 1.0.0 have been released, and #414 has been merged. Next step will be released antsibull 0.44.0.

[felixfontein]

antsibull 0.44.0 has been released. Now we eventually need to release antsibull 1.0.0 and remove antsibull-lint.

[felixfontein]

In current main branch, antsibull-lint is not doing anything anymore (but still exists).

[felixfontein]

antsibull-lint is gone, even though we're not at 1.0.0 yet :)