Re: Split Packages files based on new section "buildlibs"
Matthias Klose <doko@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: