Amirouche, On 16/03/17 19:52, Amirouche wrote: > Héllo,
Hi! I'm not the most technically qualified person to answer this, nor the most articulate, but I'm mainly curious and slightly puzzled as to why this question keeps popping up. I hope others will join in, since I fear this hints at some fundamental misunderstandings about Guix that might hurt world d^W^W adoption. > AFAIU guix does hardcode the dependencies so that to know the > dependencies one has onlytocrawl the dependency DAG using a BFS or > something. I don't know what is the exact part in guix that does > that. It's only my understanding. This doesn't happen.[1] It takes some getting used to when you're used to old-school package managers where the resolver is A Big Deal, or even The Biggest Deal: Gentoo, anyone? But one of the many great things about functional package management à la Nix/Guix is that you don't need — or want — a dependency resolver. At all. That eliminates a lot of nasty problems, and makes others much easier to solve. Huge Deal. > What about having apt-like dependency resolution, also like npm > where version are specified in terms of "superior to", "equal to" > taking advantage of semantic versionning?[2] Guix already does ‘equal to’ better than anyone. Bit-identical, even. What does ‘superior to’ mean? Why not just specify the latest version that works? What's to gain by throwing uncertainty back into the game? Kind regards, T G-R [1]: In Guix. Correct me if I'm wrong. I'm ignoring the importer, which may eventually need to ‘solve’ things like npm version constraints when first importing npm packages. *shrugs* [2]: Side rant: the myth of semantic versioning needs to die. It tries to solve the problem of downstream machines playing a guessing game that's doomed to break (i.e. ‘apt-like dependency resolution’), by making upstream humans play a different guessing game. There is simply nothing there to take advantage of.
signature.asc
Description: OpenPGP digital signature
