!VRULIdgoKmKPzJZzjj:nixos.org

Nix Package Manager development

896 Members
For people hacking on Nix: https://github.com/NixOS/nix Nix maintainers can be reached here.188 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
11 Oct 2025
@lovesegfault:matrix.orglovesegfaultHot off the press: https://github.com/NixOS/nix/pull/1421818:43:30
@lovesegfault:matrix.orglovesegfaultHot off the press: https://github.com/NixOS/nix/pull/1421919:11:00
@Ericson2314:matrix.orgJohn Ericsonnevermind, that is just a fairly innocuous boolean field20:07:03
@Ericson2314:matrix.orgJohn Ericsonso it won't cause "that bad" of UB20:07:09
@Ericson2314:matrix.orgJohn Ericsonand we just saw the issue from the first commit20:07:15
@Ericson2314:matrix.orgJohn Ericsonso I am back to my "one bug, two symptoms" theory 20:07:31
@midischwarz12:libg.somidischwarz12 joined the room.20:27:33
@tavinator:matrix.orgtavinator

nix, or nixpkgs, does not really have a concept of multiple extant versions of a package. i see this worked around in cases of overwhelming importance with e.g. python312, python313 etc.

but in general if you need an older version of package XYZ you are dealing with a git history search and pinning to a commit

there is no fundamental reason why nixpkgs HEAD could not contain the logic for multiple versions of package XYZ

so - to start from the beginning - is there something in nix itself that keeps me from e.g. writing opentofu-1.6.3 or opentofu==1.6.3 or whatever as the package i want to install?

background: i want to introduce nix devshells in a company where this kind of situation happens all the time (i.e. some project has to be checked out from github and worked on using a list of software versions that is both brittle and not recent)

22:35:31

Show newer messages


Back to Room ListRoom Version: 6