I think you might be misunderstanding how packaging is handled in Nix. Nix devs use semi-automatic tools to convert packages from programming language ecosystems to Nix packages, but these tools still have means to properly apply patches where necessary. Whether the vendoring approach is used depends on the actual tools being used, but that is mostly irrelevant. Being able to apply patches to all intended packages is a requirement for any packaging tool because patching is absolutely essential for packaging work.
> How many packages would you need to patch on nix?
So to answer your question, you only need to change a single file. For the requests library, this one[1]. You might also be interested in how Nix manages patches for NPM packages[2]. The amount of manual fixes required is surprisingly few.
> Whether the vendoring approach is used depends on the actual tools being used, but that is mostly irrelevant.
I don't think it is though? Because...
>So to answer your question, you only need to change a single file. For the requests library, this one[1]. You might also be interested in how Nix manages patches for NPM packages[2]. The amount of manual fixes required is surprisingly few.
Right, I assume python is easier in this scenario since there are not many cases where a python project would install N different versions of one package. I don't quite understand how these work if a python project depends on separate versions?
For the nodejs part I'm more curious. node_modules sometimes contain multiple versions of the same dependency, sometimes across multiple major versions. The patching in the files seems fairly trivial sed replacements and rpath rewrites. But how would security patches be applied across versions?
I also took a quick look at the go stuff, and it seems like there is no such thing there as `deleteVendor` defaults to false thus each Go application is self-contained. How would patching dependencies work here?
> I don't quite understand how these work if a python project depends on separate versions?
For Python packages in the offical Nix repository, the packages AFAIK isn't auto-generated. In this case, Nix devs split out the common part of the package definition to resemble the following pseudocode:
> For the nodejs part I'm more curious. ... But how would security patches be applied across versions?
I guess this was a bad example, as I incorrectly assumed it was patching dependencies when it wasn't. But you can though, by matching package names. The Nix language is powerful enough to do this.
> thus each Go application is self-contained
I wasn't aware of the go situation, but this does seem to be the case. However, this looks incidental rather than it being a hard requirement. Many tools provide mechanisms to centrally maintain patches, which would work whether or not vendoring is enabled.
I think this illustrates my point though. Nix doesn't necessarily solve the overarching issue of having vendored dependencies. And it doesn't seem like it's being worked on either. There might be work on this on a pr ecosystem basis, but this isn't necessarily a goal of nixos itself.
The intention here isn't to talk shit about nix though. I just wonder why people present it as being the solution to this issue.
> How many packages would you need to patch on nix?
So to answer your question, you only need to change a single file. For the requests library, this one[1]. You might also be interested in how Nix manages patches for NPM packages[2]. The amount of manual fixes required is surprisingly few.
[1]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen... [2]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...