content/add-to-config: recommend nixpkgs for stable versions #58
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "new-mechanism"
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?
This also updates all our modules which are now passthru to nixpkgs by
default.
Signed-off-by: Raito Bezarius raito@lix.systems
lixPackageSets
in nixpkgs #61@ -25,0 +21,4 @@
- Uses up-to-date system dependencies, e.g. latest glibc, OpenSSL, AWS SDK.
- Is cached by `cache.nixos.org`, no local builds are required
- Consistent compatibility with advanced features of Nixpkgs: cross compilation or static builds.
- Using the Lix NixOS module (recommended for bleeding edge versions):
if we mean main it should link to the running main instructions.
right
@ -25,1 +23,4 @@
- Consistent compatibility with advanced features of Nixpkgs: cross compilation or static builds.
- Using the Lix NixOS module (recommended for bleeding edge versions):
- Fresh version of Lix right out of the freezer
- Ships with slightly older system dependencies, e.g. glibc, OpenSSL.
this isn't true? it's always built using the user's nixpkgs. the only way this isn't true is on non NixOS where it's our bins
this is true only if you harness the power of
follows
which very few can?hm actually we are always doing an overlay i guess and i consistently get that wrong
@ -55,3 +65,3 @@
```
# Using the Lix NixOS module
## Advanced change
HA HA HA YES
@ -58,0 +73,4 @@
```nix
{ pkgs, ... }:
{
nixpkgs.overlays = [ (self: super: {
maybe want to introduce a variable so you have the selected version in one spot
i considered that but i wanted to keep it simple
@ -58,0 +80,4 @@
nix-eval-jobs
nix-fast-build
colmena;
}) ];
do we want to mention that setting
nix = pkgs.lix
works? because it is supposed to, but i definitely think this way of using stuff we explicitly override is probably safer.i believe not, this is a too simplistic endpoint and i don't want people to learn it unnecessarily
@ -58,0 +114,4 @@
# Using the Lix NixOS module (recommended only for bleeding edge builds)
_Thank you for considering Lix bleeding edge, this helps us a lot to make Lix better._
is this referring to main? merely .latest?
main
@ -63,2 +123,4 @@
perfect time to get up, get some water, and stretch for a bit.
This only makes sense if you care about **bleeding edge builds** and you are fine
with **losing the cache** advantage of using nixpkgs.
we should be clear about what bleeding edge means. bleeding edge implies it's not received QA but this is probably not that? it's probably just-released versions right?
it means main
574313267b
to7acce1a23a
7acce1a23a
to83ab07d76b
beautiful. one small language usage problem.
@ -25,0 +20,4 @@
- Official, supported builds maintained by the `nixpkgs` contributors and the Lix team
- Is cached by `cache.nixos.org`, no local builds are required
- Consistent compatibility with advanced features of Nixpkgs: cross compilation or static builds.
- Using the Lix NixOS module, [recommended uniquely if you run main](https://wiki.lix.systems/books/lix-contributors/page/running-lix-main)
en anglais on devrait probablement dire "only recommended if you run Lix main". "uniquely" n'a pas la bonne sens ici.
merci beaucoup
@ -70,2 +72,3 @@
{ pkgs, ... }:
{
inputs = {
nixpkgs.overlays = [ (self: super: {
pedantry which you can ignore: maybe use final, prev.
@ -160,2 +96,3 @@
great time to check out some of the [community's resources on Nix](/resources).
---
To use a different version of Lix, replace `stable` with `latest`, `git`, or a specific version like `lix_2_93`.
we might actually want to obliterate this entire non-flakes section because it's now exactly the same (HA HA HA YESSSSS), but i can't quite read this diff at the moment, so it's probably better to do in a separate PR.
It's already obliterated AFAIK?
83ab07d76b
to1579252c23