lix-project/lix-website
4
1
Fork 20
Code Issues 5 Pull requests 2 Projects Releases Packages Wiki Activity

2.92 release blog post #39

Merged
jade merged 1 commit from jade/2.92-blog into main 2025-01-19 01:06:06 +00:00
Conversation 6 Commits 1 Files changed 1 +335
jade commented 2025-01-18 02:54:43 +00:00
Owner
Copy link
No description provided.
jade force-pushed jade/2.92-blog from a4ca7f4bd3 to 4e1ab677ca 2025-01-18 03:16:10 +00:00 Compare
kfearsoff reviewed 2025-01-18 05:14:12 +00:00
kfearsoff left a comment
Member
Copy link

This release post brings joy to me. It's written in a thoughtful way with occasional playful jabs. It's what I would like the release notes to be.

As it happens, there are some things to improve! Nothing major, mostly just nitpicks and small areas of improvement. Those are bound to appear when the text in review has taken a lot of time to write.

Excellent job!

This release post brings joy to me. It's written in a thoughtful way with occasional playful jabs. It's what I would like the release notes to be. As it happens, there are some things to improve! Nothing major, mostly just nitpicks and small areas of improvement. Those are bound to appear when the text in review has taken a lot of time to write. Excellent job!
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +31,4 @@
Once this work is done, protocol replacement work can commence, which will enable much better visibility into the daemon and make managing large builds a lot clearer.
Lix 2.92 brings a significant refactoring of the build state machine of the daemon to use modern async.
This is expected to bring about a performance improvement while building large numbers of derivations in parallel, but is primarily an improvement in maintainability.
kfearsoff commented 2025-01-18 04:45:57 +00:00
Member
Copy link

These 2 paragraphs read a little bit awkwardly. It goes back and forth in what is says. Reading sentence by sentence, the sentiment is: "we'll replace legacy protocol in the future" -> "here's what we've done" -> "but the replacement will be in the future" -> "here's what we've done" -> "it's a bit better, but the main improvement will be in the future". It's a bit of a wild ride.

May I suggest grouping the topics together? It would be something like "we're planning to replace the protocol, it will have benefits and give better visibility into the daemon, it's also easier to maintain", and then "to that end, we have refactored the build state machine to use modern async, you may see performance improvements on large builds as a result"? Paraphrasing, of course.

These 2 paragraphs read a little bit awkwardly. It goes back and forth in what is says. Reading sentence by sentence, the sentiment is: "we'll replace legacy protocol in the future" -> "here's what we've done" -> "but the replacement will be in the future" -> "here's what we've done" -> "it's a bit better, but the main improvement will be in the future". It's a bit of a wild ride. May I suggest grouping the topics together? It would be something like "we're planning to replace the protocol, it will have benefits and give better visibility into the daemon, it's also easier to maintain", and then "to that end, we have refactored the build state machine to use modern async, you may see performance improvements on large builds as a result"? Paraphrasing, of course.
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +41,4 @@
`x:x` is a URL literal and thus a string, which is confusing since it looks kind of like a lambda.
Supporting these also slows down our parser relatively substantially.
kfearsoff commented 2025-01-18 04:47:59 +00:00
Member
Copy link

nit: "relatively" is redundant here. If it's substantial, then it's already relative to everything else; if it's not, then the sentence lacks the thing you are being "relative" of.

nit: "relatively" is redundant here. If it's substantial, then it's already relative to everything else; if it's not, then the sentence lacks the thing you are being "relative" of.
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +48,4 @@
3
```
This is not terribly useful because it only exists for a very limited list of operators and was an implementation shortcut leaking rather than an intended feature.
kfearsoff commented 2025-01-18 04:49:22 +00:00
Member
Copy link

nit: there already was "not terribly useful" in the previous sentence, you can trim it in one place or the other, or paraphrase.

nit: there already was "not terribly useful" in the previous sentence, you can trim it in one place or the other, or paraphrase.
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +65,4 @@
```
- The legacy `let` syntax of `let { a = 2; body = a; }`.
These features should not be used in new Nix code anyway, and are neither acceptable nor used in nixpkgs today.
kfearsoff commented 2025-01-18 04:53:09 +00:00
Member
Copy link

This sentence reads a little weird? It's a little "heavy", if that makes sense. How about "these features are problematic, and Nix code that uses them is rejected in Nixpkgs and other modern Nix projects" instead?

This sentence reads a little weird? It's a little "heavy", if that makes sense. How about "these features are problematic, and Nix code that uses them is rejected in Nixpkgs and other modern Nix projects" instead?
piegames commented 2025-01-18 11:43:37 +00:00
Member
Copy link

As per my proposed addition above, I'd just remove this sentence

As per my proposed addition above, I'd just remove this sentence
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +73,4 @@
[lang-wiki]: https://wiki.lix.systems/books/lix-contributors/page/nix-lang-v2
### Potentially-breaking changes
kfearsoff commented 2025-01-18 04:58:32 +00:00
Member
Copy link

I'm not sure how to feel about this header. Are those changes actually "breaking" or not? What does it mean to be "potentially" breaking?

From what I see, those changes are actually breaking: so maybe change the header to "breaking changes"? If you want to emphasize that they shouldn't affect many people, best do so in a paragraph following the header. Though I'm not sure if that's even needed: you've already justified those breaking changes well enough, you justify them in place too, and you provide migration paths where possible; that's all one could ask for!

I'm not sure how to feel about this header. Are those changes actually "breaking" or not? What does it mean to be "potentially" breaking? From what I see, those changes *are* actually breaking: so maybe change the header to "breaking changes"? If you want to emphasize that they shouldn't affect many people, best do so in a paragraph following the header. Though I'm not sure if that's even needed: you've already justified those breaking changes well enough, you justify them in place too, and you provide migration paths where possible; that's all one could ask for!
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +83,4 @@
S3 and git+ssh and suchlike use a different system and are unaffected.
Sorry to anyone using Lix to connect to Gopher servers!
Or, to devious catgirls abusing Gopher for server-side request forgery or posting to IRC from the evaluator.
kfearsoff commented 2025-01-18 04:59:41 +00:00
Member
Copy link

I love those lines. Seriously. This puts a smile on my face and makes me reassured; this is a good feeling to invoke in the release notes! Love it.

I love those lines. Seriously. This puts a smile on my face and makes me reassured; this is a good feeling to invoke in the release notes! Love it.
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +239,4 @@
- `builtins.fetchGit` is better behaved thanks to [ma27]: you can now pass tag names as `ref =` and it will work.
This restores compatibility with CppNix 2.3.
- `auto-optimise-store` no longer possibly causes store corruption on macOS, thanks to [lilyball].
kfearsoff commented 2025-01-18 05:04:35 +00:00
Member
Copy link

nit: "no longer possibly causes" is weirdly worded. Maybe "stopped causing", "no longer causes", "can no longer cause", or "no longer causes possible store corruption"?

nit: "no longer possibly causes" is weirdly worded. Maybe "stopped causing", "no longer causes", "can no longer cause", or "no longer causes possible store corruption"?
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +244,4 @@
- S3 binary cache stores now use the proxy environment variables thanks to the sleuthing of [jade].
- Flakes and restricted evaluation mode now correctly check whether paths are allowed thanks to [eldritch horrors].
Thanks to the reporter for telling us about this via the security report process.
kfearsoff commented 2025-01-18 05:05:13 +00:00
Member
Copy link

nit: would be helpful to have the hyperlink to the info on security report process here!

nit: would be helpful to have the hyperlink to the info on security report process here!
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +246,4 @@
- Flakes and restricted evaluation mode now correctly check whether paths are allowed thanks to [eldritch horrors].
Thanks to the reporter for telling us about this via the security report process.
This was treated as a minor security bug, but it is not a violation of the security model as documented: Nix code being evaluated should be assumed, for security purposes, to be able to see whatever the user running the evaluator can see, since the Lix evaluator is not a security boundary.
kfearsoff commented 2025-01-18 05:08:33 +00:00
Member
Copy link

This is a little too security-minded. Can you dumb it down? Something like "we treated it like a minor security bug; Lix evaluator isn't a security boundary and shouldn't be treated like such", maybe?

Also, would be very helpful to include the hyperlink to the "security model as documented" here!

This is a little too security-minded. Can you dumb it down? Something like "we treated it like a minor security bug; Lix evaluator isn't a security boundary and shouldn't be treated like such", maybe? Also, would be very helpful to include the hyperlink to the "security model as documented" here!
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +299,4 @@
[beta-guide]: https://wiki.lix.systems/books/lix-contributors/page/lix-beta-guide
Onwards and upwards for the next release.
We look forward to continuing to work together with everyone to build a better foundation for the future evolution of Nix.
kfearsoff commented 2025-01-18 05:09:59 +00:00
Member
Copy link

nit: doesn't "evolution" already imply "future" in this context?

nit: doesn't "evolution" already imply "future" in this context?
jade marked this conversation as resolved
piegames reviewed 2025-01-18 11:50:43 +00:00
piegames left a comment
Member
Copy link

(My browser crashed and doesn't show me the comments, lets hope they will show up if I send it)

(My browser crashed and doesn't show me the comments, lets hope they will show up if I send it)
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +35,4 @@
[KJ]: https://github.com/capnproto/capnproto
On the language side, Lix intends to first deprecate into an error (while still accepting such code with an optional setting) the most problematic unused features of the existing Nix language like the ones listed below.
piegames commented 2025-01-18 11:40:32 +00:00
Member
Copy link

On the language side, Lix is deprecating several problematic Nix language features, both to remove foot guns for users and to improve code maintainability.
Using any of these deprecated features will throw an error or warning at parse time; There is a configuration opt-out of the new behavior for each individual feature.
This means that old Nix code can still be run with a CLI flag. However, this should never be necessary except for very old Nixpkgs checkouts.

> On the language side, Lix is deprecating several problematic Nix language features, both to remove foot guns for users and to improve code maintainability. > Using any of these deprecated features will throw an error or warning at parse time; There is a configuration opt-out of the new behavior for each individual feature. > This means that old Nix code can still be run with a CLI flag. However, this should never be necessary except for *very* old Nixpkgs checkouts.
jade commented 2025-01-18 22:14:38 +00:00
Author
Owner
Copy link
lix/lix4 » nix eval --expr https://foo                                                                                                      HEAD
error: URL literals are deprecated, allow using them with --extra-deprecated-features url-literals
       at «string»:1:1:
            1| https://foo
             | ^

I should have absolutely communicated better about this far earlier, but this is the one that's actually going to break some peoples' stuff who are not super pedantic about code quality, and probably should have been a warning :/

These do need to get out of the ecosystem though.

``` lix/lix4 » nix eval --expr https://foo HEAD error: URL literals are deprecated, allow using them with --extra-deprecated-features url-literals at «string»:1:1: 1| https://foo | ^ ``` I should have absolutely communicated better about this far earlier, but this is the one that's actually going to break some peoples' stuff who are not super pedantic about code quality, and probably should have been a warning :/ These do need to get out of the ecosystem though.
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +36,4 @@
[KJ]: https://github.com/capnproto/capnproto
On the language side, Lix intends to first deprecate into an error (while still accepting such code with an optional setting) the most problematic unused features of the existing Nix language like the ones listed below.
Then, we will implement a language versioning scheme so that the language can be evolved in a more robust way with auto-migration of the majority of code to new versions.
piegames commented 2025-01-18 11:32:55 +00:00
Member
Copy link

Please remove that line, I don't want to be too loud about this yet. Moreover, the deprecations are related but separate efforts to my Nix 2 experiments.

Please remove that line, I don't want to be too loud about this yet. Moreover, the deprecations are related but separate efforts to my Nix 2 experiments.
jade marked this conversation as resolved
piegames requested changes 2025-01-18 12:00:05 +00:00
piegames left a comment
Member
Copy link

The section on language deprecations needs a bit of rework, rest looks good to me

The section on language deprecations needs a bit of rework, rest looks good to me
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +66,4 @@
- The legacy `let` syntax of `let { a = 2; body = a; }`.
These features should not be used in new Nix code anyway, and are neither acceptable nor used in nixpkgs today.
Lix 2.92 implements the first part of our plan by turning these legacy language constructs into soft errors (big thanks to [piegames]!).
piegames commented 2025-01-18 11:55:10 +00:00
Member
Copy link

Actually most of them already are errors. Instead:

To ease migration, only arcane language features are currently turned into parser errors.
Features that are still occasionally in use just give a warning instead, which will then be upgraded to an error in a future update.
Either way, the opt-out mechanism is intended to stay for a long time, to allow for backwards compatibility

Actually most of them already are errors. Instead: > To ease migration, only arcane language features are currently turned into parser errors. > Features that are still occasionally in use just give a warning instead, which will then be upgraded to an error in a future update. > Either way, the opt-out mechanism is intended to stay for a long time, to allow for backwards compatibility
jade marked this conversation as resolved
content/blog/2025-01-18-lix-2.92-release.md Outdated
@ -0,0 +75,4 @@
### Potentially-breaking changes
- The above-listed legacy language constructs generate an error unless you enable the appropriate `deprecated-features` thanks to [piegames].
piegames commented 2025-01-18 11:55:45 +00:00
Member
Copy link

and [eldritch horrors] !

and [eldritch horrors] !
jade marked this conversation as resolved
raito approved these changes 2025-01-18 12:56:52 +00:00
raito left a comment
Owner
Copy link

LGTM on my end.

LGTM on my end.
jade force-pushed jade/2.92-blog from 4e1ab677ca to eea889083e 2025-01-19 01:05:15 +00:00 Compare
jade merged commit 93f7ac3178 into main 2025-01-19 01:06:06 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
piegames
raito
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix-website#39
No description provided.
Delete branch "jade/2.92-blog"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?