Allow to use constraints files for new-ansible and prepare #546
Conversation
felixfontein
force-pushed
the
constraints
branch
from
28cc2d9 to
fee4588
Compare
|
@gotmax23 since we want to release 9.0.0a1 tomorrow (or if not then, soon), and since we have four collections whose latest versions aren't tagged (ansible-community/ansible-build-data#223 (comment)), we really need some mechanism to enforce constraints / override versions. I've started adding minimal changes to antsibull-core (see ansible-community/antsibull-core#99) to allow restricting collection versions, created a PR for ansible-build-data with the constraints needed (ansible-community/ansible-build-data#300), and did the main impementation here to allow constraints files. What do you think? |
|
(CI will fail until the other two PRs have been merged.) |
felixfontein
force-pushed
the
constraints
branch
from
3744042 to
e0192af
Compare
This makes it easier to adjust that code without having to modify ansible-core and have a new release of it, and depend on that new release.
felixfontein
force-pushed
the
constraints
branch
from
e0192af to
aeb1c8f
Compare
|
I decided to not use I think this logic is better placed here anyway since antsibull's purpose (among others) is to determine the versions of collections to be included in Ansible, so offloading parts of that logic to another library (which only wants to provide a rather minimalistic interface for that) doesn't feel right anyway. |
| build_step_parser.add_argument( | ||
| "--constraints-file", | ||
| default=None, | ||
| help="File containing a list of constraints for collections" | ||
| " included in Ansible. This is considered to be relative to" | ||
| " --build-data-dir. The default is" | ||
| " $BASENAME_OF_BUILD_FILE-X.Y.constraints", |
There was a problem hiding this comment.
Can we create a constraints_parser that contains this argument that build_step_parserandnew_parser` inherit instead of defining this argument twice?
There was a problem hiding this comment.
The descriptions for the two options differ w.r.t. the default value. One uses the basename of the build file, while the other uses the basename of the pieces file. That's also why --build-file both shows up in the same two parsers.
|
Triggering CI |
Co-authored-by: Maxwell G <maxwell@gtmx.me>
|
Other than that, I think we can merge and release this. |
Co-authored-by: Maxwell G <maxwell@gtmx.me>
|
Pyre complains: |
This reverts commit 94b39a5.
|
I reverted this so we can get this merged and released. Let's re-do it in a follow-up afterwards. |
|
@gotmax23 thanks a lot for reviewing this! |
|
#548 re-does the filename type changes. |
Needs
ansible-community/antsibull-core#99 andansible-community/ansible-build-data#300.