I hate that I have to say this, but be aware that one cannot "pip install ansible==2.13" (https://pypi.org/project/ansible/#history) since they took over the "ansible" name to mean the "ansible distribution", which includes the project you linked to as well as a bazillion separately versioned galaxy dependencies
Is pip an end user's package manager or is it a developer's dependency manager?
This is why language specific tools always gave me pause. It's focused on supporting the language and not the end user. I can't happily install programs from an array of languages anymore using a single common tool anymore. I have all this annoying overhead to memorize instead:
- Mapping which program comes from what language
- How to install things using that language's package/dependency manager
- How to access those programs, if they aren't installed to a common location
I hear you, and we do run into that _a lot_ in triaging SO reports since some folks "apt-get install ansible", others "sudo pip install", and rarest of them all "python -m venv && pip install" and the end result matters a great deal as far as "sure, the thing was installed, but WHERE and was it installed completely?"
I used "pip install" because it was shorthand, but the problem manifests with "brew install ansible" also since at this moment it says "5.7.1" but with a totally wrong `head "https://github.com/ansible/ansible.git", branch: "devel"`
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 :)
When would you ever want to install just the core without any plugins? It seems like what they have now, 'pip install ansible' and you get a working distribution, is exactly what users expect.
It's just unintuitive that the package that provides the "ansible" binary isn't ansible. And then it gets even more confusing with the title of this post. It should really be "ansible-core 2.13".
I guess that depends on ones definition of "users," since a *lot* of ansible troubleshooting involves looking at the sources for stuff due to the lack of defensive programming
But, "looking at the sources" is now extremely complicated since the "user" reports "I installed ansible==5.7.1" -- so which URL do I go to in order to see why "{{ lookup('something') }}" has IndexError-ed?
For the kind of product that Ansible is, yes, users will care. Tooling ecosystems are just like managing a programming language and all its dependencies. It's congruent to if you pulled github.com/golang/go and only got the go compiler but none of the standard library.
Your analogy has some holes. Go doesn't direct end users to pull from github and `git pull` is not expected to manage dependencies.
The root of this problem is whether pip is an end user's package manager, where a meta package makes sense, or is it a developer's tool, where you want to manage finer grained dependencies?
Actually, it does if you already have go installed (eg: install a new version[1]) can be installed with go install. In that way modules act like a system version of Pip. I do see your point though, at the least it's confusing to unpack.
But that's the opposite of what's being argued here. Their claim is that pulling down package 'ansible' should only give you the ansible binary, not ansible binary plus all the plugins and stuff to use the tool and ecosystem.
Yes, users should definitely care. Knowing the version is important for identifying which features you can use and for replicating errors for debugging, while knowing your dependency tree is important for keeping your build compact and minimizing exposure to security vulnerabilities.
I’m a fan of Ansible in general and this is not a world-ending mistake, but should be corrected to avoid confusion.
For example, "ansible 5.7.1" is actually this: https://github.com/ansible-community/ansible-build-data/blob... which includes "ansible" 2.12.5
It makes even talking about it hard