Fediversity/simple-nixos-fediverse
Archived
7
1
Fork 2
Code Issues 23 Pull requests 1 Actions Projects Wiki Activity

pixelfed-from-lock #23

Closed
roberth wants to merge 4 commits from pixelfed-from-lock into pixelfed-on-metal
pull from: pixelfed-from-lock
merge into: Fediversity:pixelfed-on-metal
Conversation 8 Commits 4 Files changed 5 +35 -12
roberth commented 2024-09-23 12:15:32 +02:00
First-time contributor
Copy link

This takes the package from the nixpkgs input instead of whatever pkgs is. This way the module can be imported into NixOS stable and still use the same package.

This takes the package from the nixpkgs input instead of whatever pkgs is. This way the module can be imported into NixOS stable and still use the same package.
roberth added 2 commits 2024-09-23 12:15:33 +02:00 
import drops it
roberth commented 2024-09-23 12:15:46 +02:00
Author
First-time contributor
Copy link

Haven't done the other services; still testing...

Haven't done the other services; still testing...
roberth changed target branch from main to pixelfed-on-metal 2024-09-23 12:16:54 +02:00
taeer reviewed 2024-09-25 01:58:50 +02:00
flake.nix Outdated
@ -23,0 +45,4 @@
./vm/pixelfed-vm.nix
self.nixosModules.fediversity
];
};
taeer commented 2024-09-25 01:58:34 +02:00
Collaborator

Can you explain what makes this organization better than the one we currently have? I don't have an intuition either way so I'd like to understand the motivation for the change.

Can you explain what makes this organization better than the one we currently have? I don't have an intuition either way so I'd like to understand the motivation for the change.
taeer commented 2024-09-25 06:42:17 +02:00
Collaborator
Copy link

I implemented a variation on your changes here d910dfe788. Let me know what you think.

I implemented a variation on your changes here https://git.fediversity.eu/taeer/simple-nixos-fediverse/commit/d910dfe78864d4656200cbb3e12a00c2c4537711. Let me know what you think.
roberth force-pushed pixelfed-from-lock from 46385f6174 to 1fc83f6980 2024-09-25 09:42:19 +02:00 Compare
roberth commented 2024-09-25 13:25:57 +02:00
Author
First-time contributor
Copy link

I prefer to avoid overlays, and I think we should decide the package version for our users, because that's essential for being able to control quality.

?

I did make a mistake coding this up (during a meeting fwiw), so what I really intended was to also have 46385f6174..1fc83f6980

So it makes the modules actually use the packages from the nixpkgs that we're locking and testing in this repo.
Alternatively, we could take them from self.packages instead.

I prefer to avoid overlays, and I think we should decide the package version for our users, because that's essential for being able to control quality. > ? I did make a mistake coding this up (during a meeting fwiw), so what I really intended was to also have https://git.fediversity.eu/taeer/simple-nixos-fediverse/compare/46385f61741039010fd31b82c9b53ddf2f0652a3..1fc83f6980041c6add47b8dd46758329d5c85842 So it makes the modules actually use the packages from the nixpkgs that we're locking and testing in this repo. Alternatively, we could take them from `self.packages` instead.
roberth commented 2024-09-25 13:27:57 +02:00
Author
First-time contributor
Copy link

Oh wait no actually that pkgs it referenced was inputs.nixpkgs.legacyPackages anyway, but I got confused for a sec. Anyway, it's more flexible now, and if you import it into an aarch64-linux NixOS, at least you'll get an error early.

Oh wait no actually that `pkgs` it referenced was `inputs.nixpkgs.legacyPackages` anyway, but I got confused for a sec. Anyway, it's more flexible now, and if you import it into an `aarch64-linux` NixOS, at least you'll get an error early.
roberth added 1 commit 2024-09-25 13:29:50 +02:00
Niols commented 2024-09-25 16:51:19 +02:00
Owner
Copy link

I prefer to avoid overlays, and I think we should decide the package version for our users, because that's essential for being able to control quality.

I am now quite convinced with deciding the package version for our users. I fail to see the link with overlays; what's wrong with them?

> I prefer to avoid overlays, and I think we should decide the package version for our users, because that's essential for being able to control quality. I am now quite convinced with deciding the package version for our users. I fail to see the link with overlays; what's wrong with them?
roberth commented 2024-09-27 09:44:23 +02:00
Author
First-time contributor
Copy link

overlays; what's wrong with them?

It's a mechanism for modifying the package set; not purely extending them. This makes them less modular than other mechanisms, because if any two overlays touch the same attribute, we now have to reason about their effect and keep track of the order in which those overlays are applied.
We're also using the module system, which - while it has mechanisms to handle this ordering - they aren't capable enough, and nobody should have to even think about such an unnecessary complexity.
In other words, they're a form of "global" state, not unlike /usr on a traditional distribution.
The insidious things is that it works fine most of the time, until you get yourself into a mess with a project that doesn't just add its own unique attribute.

When writing reusable modules, we are not the arbiter of the nixpkgs.overlays option anymore. That's up to the user of the module. We'd have to inform them which attributes we change in their Nixpkgs, and they'd have to be ok with those changes.
That's not how it works in practice. The process is just trial and error.

While the error part in trial and error tends to be rare, we didn't come here to maybe replicate the issues of /usr.
So the question becomes, what mechanisms do we have?

  • Overlays:
    • everything is tied to a name: global state
    • allows modification of any package in Nixpkgs, much like patching the nixpkgs repo
  • Lexical scope:
    • objects are independent, not tied to a name
    • new bindings do not create changes in other parts of the expression (modulo shadowing; names are inconsequential, so you can always pick a free one without consequences)

From this we can infer their purpose:

  • Overlays: changing the package set
  • Lexical scope: creating new independent packages

So to answer the question, the only thing wrong with overlays is their usage in adding new and independent packages. They are ok for making changes to existing packages, because in that use case we've already accepted the fundamental issues with "global state" and with overriding. However, we don't need that.

That's not to say that we mustn't ever use overlays.
We may get into a situation where we need to override a deep dependency, and overlays are the best mechanism for that. However, that doesn't mean that we have to force overlays on the module's users. Instead we can apply the overlay to our local pkgs in this flake, so that it has the overrides (and only the overrides we want), and then we can refer to that pkgs instead of the NixOS global pkgs module argument that is controlled by our user.

> overlays; what's wrong with them? It's a mechanism for modifying the package set; not purely extending them. This makes them less modular than other mechanisms, because if any two overlays touch the same attribute, we now have to reason about their effect and keep track of the order in which those overlays are applied. We're also using the module system, which - while it has mechanisms to handle this ordering - they aren't capable enough, and nobody should have to even think about such an unnecessary complexity. In other words, they're a form of "global" state, not unlike `/usr` on a traditional distribution. The insidious things is that it works fine most of the time, until you get yourself into a mess with a project that doesn't just add its own unique attribute. When writing reusable modules, we are not the arbiter of the `nixpkgs.overlays` option anymore. That's up to the user of the module. We'd have to inform them which attributes we change in their Nixpkgs, and they'd have to be ok with those changes. That's not how it works in practice. The process is just trial and error. While the error part in trial and error tends to be rare, we didn't come here to maybe replicate the issues of `/usr`. So the question becomes, what mechanisms do we have? - Overlays: - everything is tied to a name: global state - allows modification of any package in Nixpkgs, much like patching the nixpkgs repo - Lexical scope: - objects are independent, not tied to a name - new bindings do not create changes in other parts of the expression (modulo shadowing; names are inconsequential, so you can always pick a free one without consequences) From this we can infer their purpose: - Overlays: changing the package set - Lexical scope: creating new independent packages So to answer the question, the only thing wrong with overlays is their usage in adding new and independent packages. They are ok for making changes to existing packages, because in that use case we've already accepted the fundamental issues with "global state" and with overriding. However, we don't need that. That's not to say that we mustn't ever use overlays. We may get into a situation where we need to override a deep dependency, and overlays are the best mechanism for that. However, that doesn't mean that we have to force overlays on the module's users. Instead we can apply the overlay to our local `pkgs` in this flake, so that it has the overrides (and only the overrides we want), and then we can refer to that `pkgs` instead of the NixOS global `pkgs` module argument that is controlled by our user.
Niols closed this pull request 2024-09-30 12:23:05 +02:00
Niols commented 2024-09-30 12:25:14 +02:00
Owner
Copy link

Ah, I didn't realise this was still tracking pixelfed-on-metal and had not shifted to targetting main. I fear you might have to open a new PR.

Ah, I didn't realise this was still tracking `pixelfed-on-metal` and had not shifted to targetting `main`. I fear you might have to open a new PR.
👍 1
roberth commented 2024-10-06 00:34:40 +02:00
Author
First-time contributor
Copy link

overlays; what's wrong with them?

I just wasted hours on a project that defined sources in an overlay for convenient access to the pins. Isn't a package, so should be fine? Nope. It affects all callPackage calls where the function has a default for sources, including a dependency of gitlab.
Completely unrelated error of course, and I was lucky to find it as soon as I did - basically unsolvable unless you're already aware of these risks.

> overlays; what's wrong with them? I just wasted hours on a project that defined `sources` in an overlay for convenient access to the pins. Isn't a package, so should be fine? Nope. It affects all `callPackage` calls where the function has a default for `sources`, including a dependency of `gitlab`. Completely unrelated error of course, and I was lucky to find it as soon as I did - basically unsolvable unless you're already aware of these risks.
This repo is archived. You cannot comment on pull requests.
Reviewers
No reviewers
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
3 participants
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: Fediversity/simple-nixos-fediverse#23
No description provided.
Delete branch "pixelfed-from-lock"

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?