I believe it's likely just a nomenclature problem; had they left "ansible" pointing at GH/ansible/ansible and called the new thing "superansible" (or whatever) it would have been so much easier to reason about and wouldn't have needed a damn near secret side-repo named "ansible-build-data" in which they would hide the actual, no kidding, git tags
The first time someone had to create a GH release named "these are not the releases you're looking for" would have been a great opportunity to acknowledge how off the rails things had gone: https://github.com/ansible/ansible/releases/tag/v2.2.1.0-0.3...
Related to that, I consider it almost purposefully misleading of them to leave the PyPI "source" link pointed at GH/ansible/ansible since that is _for sure_ not what is going to be pip installed for those version numbers. It'd be like pointing the ansible PyPI at the Jinja2 GH repo -- yes, that is one of the things that pip installing will put on disk, but where did the rest of it come from?
I hope you don't mind me stealing your comment to plug my side project, Judo. It was created in 2016, out of my frustration with Ansible. Judging by the state of affairs, that motivation continues to be relevant.
That's one of the design decisions, there should ideally be only one "obvious" way of achieving a certain goal. Per-invocation parameters can already be passed via environment variables ("-e FOO" to pass from your local environment; "-e BAR=42" to set explicitly); I'm also considering using envdir (or a similar scheme) to set per-host parameters (https://github.com/rollcat/judo/issues/11).
I could allow specifying command line arguments somehow with the -s flag, but that would complicate parsing, quoting/unquoting, etc. I would have to teach the user about quoting rules, and probably shoot myself in the foot at least once in the process. I try to actively avoid creating hard problems by solving an equivalent, easier problem.
If this is not clear from the readme, I'll take this as a bug report, and try to improve the readme :)
The first time someone had to create a GH release named "these are not the releases you're looking for" would have been a great opportunity to acknowledge how off the rails things had gone: https://github.com/ansible/ansible/releases/tag/v2.2.1.0-0.3...
Related to that, I consider it almost purposefully misleading of them to leave the PyPI "source" link pointed at GH/ansible/ansible since that is _for sure_ not what is going to be pip installed for those version numbers. It'd be like pointing the ansible PyPI at the Jinja2 GH repo -- yes, that is one of the things that pip installing will put on disk, but where did the rest of it come from?