You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorin and I talked about the vendoring strategies the other day. So let me document a few I know of:
Implement the same ansible-core has: https://github.com/ansible/ansible/tree/97ef1d0/lib/ansible/_vendor. TL;DR they have an empty directory within the repository that is auto-added to the Python import path and if downstream packagers have problems with packaging the dependencies from PyPI separately, they could drop in those right in this directory and it'll work magically without forcing them to also package those deps.
Implement what setuptools does: Stop vendoring packages pypa/setuptools#2825 / Declare dependencies in metadata pypa/setuptools#2764. TL;DR there's efforts to stop/minimize special-casing of the deps as much as possible and let downstreams do their thing. Where not possible, they'll try to use the vendoring package made by the pip maintainers. This option is mostly about not caring on the upstream side and solving the problem within the spec file.
Summary
Vendor enrich library to reduce packaging dependency https://pypi.org/project/enrich/
Based on the usability research viability to move it to ansible-compat library
Issue Type
OS / ENVIRONMENT
RPM-based downstreams
Desired Behaviour
An unpackaged downstream dependency shouldn't get in the way of packaging our project for that ecosystem.
Actual Behaviour
In order to package our project, it is also necessary to package extra projects like enrich that are our dependencies.
The text was updated successfully, but these errors were encountered: