The package name for Ansible changes with the current development version.
It seems like pip lets me install Ansible 2.9 and 2.10 at the same time…
bash-4.4# pip3 show ansible
Name: ansible
Version: 2.9.7
Summary: Radically simple IT automation
Home-page: https://ansible.com/
Author: Ansible, Inc.
Author-email: info@ansible.com
License: GPLv3+
Location: /usr/local/lib/python3.6/site-packages
Requires: jinja2, PyYAML, cryptography
The directory ‘/var/lib/awx/.cache/pip/http’ or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
bash-4.4# pip3 show ansible-base
Name: ansible-base
Version: 2.10.0.dev0
Summary: Radically simple IT automation
Home-page: https://ansible.com/
Author: Ansible, Inc.
Author-email: info@ansible.com
License: GPLv3+
Location: /usr/local/lib/python3.6/site-packages
Requires: jinja2, PyYAML, cryptography
The directory ‘/var/lib/awx/.cache/pip/http’ or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
Is there a use case for this? Would it be a reasonable request for guard rails of some kind?
This is known and expected right now. Technically there is no ansible 2.10 right now. There is ansible-base which is a different package name. Eventually there will also be an ansible that has deps on ansible-base.
But python packaging doesn’t really offer guards around this. Look at docker vs docker-py. 2 package names that both provide docker, produced by the same author.
If a user who has ansible==2.9.7 installed installs ansible-base==2.10, we can’t really prevent it. We’ve discussed this internally on a few occasions.
We can add docs to tell people if they plan to upgrade ansible to ansible-base explicitly, that ansible needs to be removed. However, eventually when ansible (we’ve been calling this ACD) is released, a user doing pip install -U ansible would have things in working order.
OS packaging has ways to prevent it, such as Conflicts in rpms.
But python packaging doesn't really offer guards around this. Look at `docker` vs `docker-py`. 2 package names that both provide `docker`, produced by the same author.
If a user who has `ansible==2.9.7` installed installs `ansible-base==2.10`, we can't really prevent it. We've discussed this internally on a few occasions.
Not sure if I'm missing the point here … while Python packaging
doesn't allow to specify conflicting packages, it *is* possible
to put code into `setup.py` that checks for the other package and
e.g. issues a warning during installation.
(apologies for leaving the list off when I replied initially)
Hmmm… There not going to be a repo that has the ansible sources (since it will be constructed from separate collections) so I wonder what the best substitute is for that second line. Perhaps if I upload an ansible test package to test.pypi.org and then you can pip install ansible --extra-index-url https://test.pypi.org/simple ?
I discovered that the present dependencies I’m coding don’t work with prerelease version numbers so I have to fix that before uploading to test.pypi but that might work once I do?