3 ms·

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 sh

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".

qbasic_forever 4y ago
Should users care?
- mdaniel 4y ago
  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? I cheated in asking you that, since it depends on what "something" is in that stanza, given that "{{ lookup('ini') }}" is hosted at https://github.com/ansible/ansible/blob/v2.12.5/lib/ansible/plugins/lookup/ini.py https://github.com/ansible/ansible/blob/v2.12.5/lib/ansible/... but "{{ lookup('dig') }}" lives in https://github.com/ansible-collections/community.general/blob/4.8.0/plugins/lookup/dig.py https://github.com/ansible-collections/community.general/blo... and to even get that number, I had to go sniffing in "lib/python3.10/site-packages/ansible_collections/community/general/MANIFEST.json" to know
- kodah 4y ago
  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.
  - qbasic_forever 4y ago
    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.
  - Steltek 4y ago
    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?
    - kodah 4y ago
      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. 1: https://go.dev/doc/manage-install https://go.dev/doc/manage-install
- divbzero 4y ago
  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.

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".

qbasic_forever 4y ago

Should users care?

mdaniel 4y ago
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? I cheated in asking you that, since it depends on what "something" is in that stanza, given that "{{ lookup('ini') }}" is hosted at https://github.com/ansible/ansible/blob/v2.12.5/lib/ansible/plugins/lookup/ini.py https://github.com/ansible/ansible/blob/v2.12.5/lib/ansible/... but "{{ lookup('dig') }}" lives in https://github.com/ansible-collections/community.general/blob/4.8.0/plugins/lookup/dig.py https://github.com/ansible-collections/community.general/blo... and to even get that number, I had to go sniffing in "lib/python3.10/site-packages/ansible_collections/community/general/MANIFEST.json" to know
kodah 4y ago
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.
- qbasic_forever 4y ago
  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.
- Steltek 4y ago
  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?
  - kodah 4y ago
    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. 1: https://go.dev/doc/manage-install https://go.dev/doc/manage-install
divbzero 4y ago
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.