Jason R. Coombs

# Solution Recent advancements in specifications and tooling around packaging promise to help address some of the issues above. The solution proposed herein is that Setuptools should: (a) Declare its...

The readme for vendoring talks only about how the project is used for pip only and provides no guidance on how to use it. I guess you're proposing that I...

In pradyunsg/vendoring#37, I learned that the vendoring project is uninterested in supporting the complexity of Setuptools, so if Setuptools were to adopt vendoring, it would need to at the very...

In https://github.com/pypa/setuptools/issues/4455#issuecomment-2203461914, I've been thinking maybe there's a better way to vendor dependencies that's far less intrusive and doesn't require re-writing the vendored packages. I'm exploring that now.

> For the record, one risk I see is that if the user has an incompatible version of the dependency installed, setuptools would use it rather than the "vendored" fallback...

In #4457, I'm pleased to say I have an initial proof of concept that applies the concept and is largely working. There are some mypy tests failing, but I'm confident...

I can see the underlying error in the traceback. > canonicalize_version() got an unexpected keyword argument 'strip_trailing_zero' That's been reported in #4483. I'll be very interested to learn if it's...

Thanks! Long-term, I'm hoping that setuptools can declare it's actual dependencies, but the problem is probably one of the hardest ones in the Python ecosystem (https://github.com/pypa/packaging-problems/issues/342).

> (in my mind treating it as "mostly" vendorised is imprecise, a closer analogy are generators closer like protobuf) Thanks for the clarification. In that case, I feel less strongly...

Yes. That helps a lot. Let's see how that goes.