3 ms·
> 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 AFA
by soraminazuki 6y ago
> 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:
def commonDefinition(version):
return {
'src': 'http://...',
'sha256': '000...',
...
}
packageV1 = commonDefintion(1)
packageV2 = commonDefinition(2)
> 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.
- Foxboron 6y agoI 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.