Vendoring packages is complicated. It often involves rewriting imports or pulling other tricks. Patches sometimes need to be applied.
Usually, the source of vendored libraries is included in the source tree and committed, as is the case for pip’s vendored dependencies. I’m also aware that vendoring has been extracted from pip, but doesn’t recommend 3rd party usage.
It seems that publishing tools like
setuptools could be involved in helping sort this out and make this a standard part of python packaging. The idea I’ve been thinking about is to make vendoring at build time a standard and supported behavior.
- Can packages better accommodate this if they expect to be vendored? Could packages declare themselves as
vendor_safe=True? What would this imply/require? (Pure python only? Relative imports only?)
- How would packaging with vendored libraries be declared? Would a package need to declare a namespace for its vendored dependencies?
- What is the bare minimum vendoring capability which would be useful? Does it need to support patching files?
I’m imagining that I could write one day a
setup.cfg like so:
[options] package_vendors = mypackage._vendor:requests mypackage._vendor:pyjwt[crypto]==2.3.0
and this means that when I run
python -m build
- I get a vendored copy of the latest
requestsin-tree, in the sdist
- I get a vendored copy of
- my package’s
install_requireslist is extended with the dependencies of my
requestsversion and the dependencies of
requestsdoesn’t publish a version which sets
vendor_safe=True, then the build would fail instead
Has this been discussed in the past? I’d be curious to read about past thoughts on this topic and to better understand the situation.