Can vendoring dependencies in a build be officially supported?

[sirosen (Stephen Rosen)]

@FFY00

The example you gave, jsonschema , does not have any runtime dependencies, so unless you need a very constrained version of it, depending on it should not really cause any issues.

Even if I don’t need a constrained version of it today, any time it does a breaking change (major release if you use semver), I need to consider it. jsonschema recently released 4.0, so using it would put us in the position of having to support jsonschema 3.x and 4.x in the same codebase.

Sometimes supporting multiple versions of a library is easy or near-trivial, and sometimes it is not. And maybe it’s worth bumping your own library’s major version when you update the library dependency, maintaining the old release line, and avoiding support for both versions of the upstream library in a single version of your own package.

But it demonstrates that if you care a lot about compatibility, even trivial seeming dependencies can trip you up.

@FFY00

Well, the correct answer here would be to not depend or the main branch, or …

I agree with most of your points here. I’d like to be donating some of that most precious resource – developer time – to this upstream package, but it’s not in the cards. The situation is unfortunately complicated by organizational politics. Suffice it to say: it’s even weirder than the name weird_dep suggests.

But more than anything, I agree that this case should be extremely rare.

@FFY00

I don’t think these issues you are facing are common enough in the ecosystem to justify either supporting multiple version importing or adding a feature to normal build backends, like setuptools, to support automatic vendoring.

My goal in raising this thread was not so much to solve problems I’m seeing, but to see if this is a viable approach to a class of problems that users have raised over the years, my own included.

Although rare, python users have asked in the past for built-in support, as a feature of the language, for installing multiple versions of the same package side-by-side. Some examples:

• Allowing Multiple Versions of Same Python Package in PYTHONPATH
• Installing multiple versions of a package

I wonder if such use-cases wouldn’t be satisfied if users could

[options]
package_vendors =
    mypackage._vendor.requests:requests
    mypackage._vendor.requests200:requests==2.0.0

As far as I’m concerned, the asks for support for multiple versions of a package in the language are dead on arrival. The use-cases are too rare and the “solutions” are much too expensive.
But vendoring is doable without a single commit on cpython.

All of that said, I respect any opinion that it is not worth the effort, as supporting this is no small ask.