Summary
The collection's requirements.txt ships a pip option line alongside the PEP 508 requirements:
ansible
pydantic
requests
-c constraints.txt
ansible-builder's introspection passes each line of a collection's requirements.txt through as a requirement entry into the combined build-context requirements file. The -c constraints.txt line survives introspection verbatim:
$ ansible-builder introspect <collections_path>
python:
- 'pydantic # from collection cisco.dcnm'
- 'requests # from collection cisco.dcnm'
- -c constraints.txt
In the EE build context the relative path constraints.txt does not exist (pip resolves -c relative to the combined requirements file's directory, not the collection's), so the build fails:
ERROR: Could not open requirements file: [Errno 2] No such file or directory: '.../constraints.txt'
Any execution environment that includes cisco.dcnm therefore fails to build unless the collection's entire python-requirements passthrough is excluded.
Environment
- cisco.dcnm: 3.12.0 and 3.12.1 (both ship the line;
constraints.txt in the collection contains ansible<12)
- ansible-builder: 3.1.1 (definition schema v3)
- Base image:
registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel8:latest
Expected behavior
requirements.txt contains only PEP 508 requirement lines so EE builds that include the collection succeed. If the ansible<12 constraint matters for the collection, it could be expressed as a direct requirement bound (or documented), rather than a -c option line that only resolves in the collection's own directory.
Workaround we run today
In the EE definition (schema v3), exclude the collection's python passthrough entirely and re-declare its real dependencies once at the EE level:
dependencies:
exclude:
python:
all_from_collections:
- cisco.dcnm
python: requirements.txt # re-declares pydantic + requests>=2.28 once
Happy to provide anything else that helps reproduce.
Summary
The collection's
requirements.txtships a pip option line alongside the PEP 508 requirements:ansible-builder's introspection passes each line of a collection'srequirements.txtthrough as a requirement entry into the combined build-context requirements file. The-c constraints.txtline survives introspection verbatim:In the EE build context the relative path
constraints.txtdoes not exist (pip resolves-crelative to the combined requirements file's directory, not the collection's), so the build fails:Any execution environment that includes
cisco.dcnmtherefore fails to build unless the collection's entire python-requirements passthrough is excluded.Environment
constraints.txtin the collection containsansible<12)registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel8:latestExpected behavior
requirements.txtcontains only PEP 508 requirement lines so EE builds that include the collection succeed. If theansible<12constraint matters for the collection, it could be expressed as a direct requirement bound (or documented), rather than a-coption line that only resolves in the collection's own directory.Workaround we run today
In the EE definition (schema v3), exclude the collection's python passthrough entirely and re-declare its real dependencies once at the EE level:
Happy to provide anything else that helps reproduce.