I know that there are a lot of news and cool features there but log-format being a setting is such a nice one. I’m so tired of writing –log-format multiline-with-logs everywhere
Thanks also for the nice writeup. These really help keeping up with the changes and direction 
Lix and OrigNix are two projects with fundamentally different visions (both technically and socially), which are moving in different directions and have been for almost two years now. Cross-ports do happen where it makes sense, but the codebases are slowly drifting apart beyond the point where changes to one are easily applicable to the other.
By the way this is the same discussion as it is with DetSys Nix and their efforts of upstreaming contributions: Crossstream must be willing to accept these contributions, and agree with the general direction of said contributions. In my perception there is cross-team consensus on this not being the case.
(On a side note, both of these discussions have been soured by the notion that forking is something negative, and that upstreaming and reconsolidating are thus morally imperative. In my perception, this negativity has been a major factor in DetSys’ mental gymnastics around not wanting to call their code a (Soft-)Fork of OrigNix. I think that this framing of “merging back” as an implicit goal is inherently harmful, and kindly ask to value all forks on their own merits.)
——–
P.S. I: We are working on a joint technical vision document and a roadmap for the next couple of years for Lix and where it is heading, this may still take a while but once it is published I hope that it will be way a lot easier to explain the huge differences in where each project is headed.
P.S. II: As one specific example related to this release, OrigNix has recently merged an implementation for feature deprecations. Its semantics are modeled after `-w` flags in compilers, while Lix’ implementation is a simple mirror of the existing experimental-features infrastructure. Additionally, the two projects do not share common parser code anymore, and most of the recently added deprecations live in the parser. And the language tests do not share the same code anymore either. Cross-porting any deprecations would be equivalent to re-implementing the same code but under a different framework. This is a fundamentally different workload than a simple “apply patch, fix merge conflicts” workflow
Out of curiosity, is it possible for end-users to have lix specifically error on deprecations? Or is there no way to distinguish them from other types of warnings? I know there’s abort-on-warn but that seems a bit too imprecise (there’s other warnings that I would not be able to act on right now).
There isn’t, which is a consequence of the simplistic nature of the deprecations infrastructure used. All the user settings can do is set an enable/disable flag, and whether or not the feature results in a warning or an error is hard-coded in Lix. If you want to do any further checks, use `nix-instantiate –parse –json` (for all deprecations involving the parser) or the eval logs (probably with the unstable internal JSON output format).
Note that AIUI `abort-of-warn` is about abortion at evaluation time in calls to `builtins.warn`, which is unaffected by the deprecation warnings.
In theory the infrastructure could be improved, but most of the deprecations are one-offs anyways so it’s unclear if there is much long-term value in doing that.
Will Lix maintain compatibility between Lix and Nix configs? For example, if I write my config using Nix then switch to Lix will it work with minor changes, or is their plan for more major changes?
At some point the configuration infrastructure is due for a complete overhaul. For a start, the 2.95 release now supports configuring the machines via TOML instead of the bespoke homebrew format. For now it supports both though, and probably the same will also apply to any global configuration changes to ease the transition. But long-term, there’s no guarantee for keeping full compatibility I think
Btw, are there any incompatibilities in the data stored in /nix/var between the different forks, so there would be any risk of breaking my system if i switch to using Lix and then CppNix and then Determinate Nix or something like that?
To the best of our knowledge, there’s no change in the schemes in these directories. The only source of truth database usually in Nix implementations is /nix/var/nix/db/db.sqlite — everything else can be deleted (except if you depend on nix-env) and restored cleanly from Nix expressions.
Unfortunately, we do not control what other implementations can do, so such breakages can happen.
Ehm, I’d hope for some collaboration here. Surely we do not want to have commonly used Nix forks which get developed completely independently of each other, including such breakages of compatibility?
So is nixpkgs comp going break in the future?
I think that ship has respectably sailed already.
Really? Is there such a level of not talking to each other that the parties aren’t even communicating to avoid severe breakage due to incompatible sqlite schemas?
I would’ve expected at least some basic communication for simple things like that, even if the overall visions and philosophies are completely incompatible.
I think it’s more like “nix can make a breaking change to the format and lix can’t do anything about it”. In my highly biased opinion, nix has been making a lot of changes for the sake of change, so I wouldn’t be surprised if they break this format too. Communication is moot when nix is not beholden to the goals of any fork (and ultimately, that’s the whole point behind forking, so that each variant can realise whatever vision they want).
As far as I’m concerned, this is almost how all breakages do happen, there’s contracts to hold ([nix3 CLI interfaces]( #1139 - `nix profile add` is missing in Lix - lix-project/lix - Lix Systems ), versioning JSON outputs, etc.) and they end up being broken and we learn about it because users are affected.
Ideally, there would be communication, but that communication does not really happen on a project-level because I suspect we do not all share a common culture or context when it comes to how such a project should be run and managed. We have values we explicitly list especially when it comes to code. We do not allow LLM derived contributions at all.
I cannot speak for all of the team, neither all of the Lix contributors, but I know that I hold little interest over nixpkgs compatibility in the very long term. I think that nixpkgs should be redesigned from the ground up (with a bunch of ideas that have been discussed publicly in this forum but also privately for years, especially in relation with how CA derivations should happen someday).
But very long term is very long term and today, Lix aim to support nixpkgs, we do not want our implementation to adopt what we regard as features/fixes that worsen the current state of things (sometimes, we are wrong and we conclude that it is now the only solution to achieve a certain outcome due to decades of legacy and mistakes).
To be clear, my message is not a blame towards CppNix or the CppNix team.
So I assume eventually Lix will be ejected from nixpkgs and there going be something like a lixpkgs take place right?