Matthias Klose <d...@debian.org> writes: > On 11/11/20 8:37 PM, Russ Allbery wrote:
>> Rust and Go both vendor dependencies during their build. Python isn't >> really analogous; you *can* do something similar with virtualenvs, but >> (a) Python doesn't really have a build the way that Rust and Go do >> because one generally doesn't produce native code, and (b) the >> virtualenv approach is optional and only one of many ways of assembling >> Python applications, whereas there's largely only one way Rust and Go >> binaries are built. > No, a lot of python projects do vendoring like Rust and Go. That's > different than a virtualenv. Usually you have a sub-package called > vendor or _vendor in the package namespace. I obviously have not done anywhere near as much Python packaging as you have, so maybe I'm just ignorant about this. I had thought that Python packages that did this generally distributed those packages with their releases, so this vendoring looks like the vendoring that C, some Perl, etc. does. That's a somewhat older problem for which we have long-standing approaches, and usually the vendoring is small enough scale that we can replace the vendored versions with packaged versions unless they've been heavily forked. That would be a little different than what Go or Rust do, where the dependencies aren't distributed, but instead the build system does something akin to constructing a new virtualenv (using pinned version numbers) with each build (and then compiling it into a single native executable). But maybe I'm wrong and there are Python packages that do something like pip install dependencies into a vendor directory during their build? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
