pixelfed-from-lock #23

roberth · 2024-09-23T12:15:32+02:00

roberth commented

2024-09-23 12:15:32 +02:00

First-time contributor

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

nixosModules: Preserve file name a4fedcbc44

import drops it

nixosModules: refactor and always use pixelfed from lock 46385f6174

roberth commented

2024-09-23 12:15:46 +02:00

First-time contributor

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

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

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

First-time contributor

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

First-time contributor

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

Add packages.${system}.pixelfed 114b1d596f

Niols commented

2024-09-25 16:51:19 +02:00

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

First-time contributor

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

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

First-time contributor

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.

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project

No assignees

3 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: Fediversity/simple-nixos-fediverse#23