Do not sanitize user python requirements

[Shrews]

Fixes #334

User Python requirements, specified via the --user-pip CLI option, will have duplicates removed, but will not go through the Python package exclusion process.

[Shrews]

Likely need an option to build to pass this through.

[dmsimard]

I guess this depends on the version of ansible.

After 2.9, the ansible package isn't strictly necessary and this is reflected in the published images for ansible-runner, for example:

# for version in 2.12 2.11 2.10 2.9
> do
> podman run -it quay.io/ansible/ansible-runner:stable-${version}-devel pip freeze | grep ansible
> done
ansible-core @ file:///output/wheels/ansible_core-2.12.1.post0-py3-none-any.whl
ansible-runner @ file:///output/wheels/ansible_runner-2.1.2.dev2-py3-none-any.whl
ansible-core @ file:///output/wheels/ansible_core-2.11.7.post0-py3-none-any.whl
ansible-runner @ file:///output/wheels/ansible_runner-2.1.2.dev2-py3-none-any.whl
ansible-base @ file:///output/wheels/ansible_base-2.10.16.post0-py3-none-any.whl
ansible-runner @ file:///output/wheels/ansible_runner-2.1.1.dev14-py3-none-any.whl
ansible @ file:///output/wheels/ansible-2.9.27.post0-py3-none-any.whl
ansible-runner @ file:///output/wheels/ansible_runner-2.1.2.dev2-py3-none-any.whl

After 2.10, the ansible package on pypi moved to a model where it only includes a set of collections.
My use case was to mirror the UX of installing 'ansible' from PyPI and then bumped into that issue (thanks for pointing me here)

I don't mind too much because there's simple workarounds like mentioned in that issue in addition to installing collections "manually" with a galaxy requirements.yml.

I could have missed it but it would be great to print a message that says a package was "sanitized" to avoid the effect of surprise.

[AlanCoding]

I could have missed it but it would be great to print a message that says a package was "sanitized" to avoid the effect of surprise.

I think that was attempted as a comment in the resultant requirements file, but with subsequent refactoring with the assemble script and other stuff, I think that file may wind up getting trashed, as more things were moved inside of ephemeral build stages.

ansible-builder/ansible_builder/requirements.py

Line 47 in 87ae1d6

logger.debug(f'# Excluding requirement {req.name} from {req.collections}')

[dmsimard]

@AlanCoding would it make sense to bump the verbosity of that from debug to warning, perhaps ?

[AlanCoding]

Let me put forward my alternative suggestion here - instead of documenting a new thing, we could avoid sanitizing anything from the user's requirements.

I find it hazardous to turn off sanitization of a collection's dependencies. I also don't see why we should ever sanitize the user's requirements. This would be much easier for documentation, probably just a mention in the --sanitize option help text.

To implement this, it might be adding something like and "user" not in req.collections

Just an idea. I'm always in favor of adding less configuration options if it will accomplish the same goal.

[Shrews]

Hrm, I have to consider this some more, but I sort of like this solution at first read. I think we would still want to sanitize the user requirements to remove duplicates, but skip the part where we remove the excluded packages.

[Shrews]

recheck

[AlanCoding]

This looks great to me, thanks for incorporating the feedback.

[ansible-zuul]

LGTM!

[Shrews]

Since this is a bit of a behavior change, I don't think I'm going to backport this to release_1.0.