DevOS | 35 Members | |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| Sender | Message | Time |
|---|---|---|
| 21 Jul 2021 | ||
| * So it tries to give clearly identifiable names "channel/winestreamproxy" to every overlay. Each overlay was crafted for a specific channel, which still is a local reference. But having a clue what the author regarded as "nixpkgs" at the time of crafting an overlay might get the consumer an idea with which channel of his own this overlay probably might have a better chance of working. | 20:36:56 | |
in the end, the cuonsumer has to try to know for sure, but if there is something like nixos-19.03/some, then the user might probably be able to guess that it's not going to work with master | 20:37:39 | |
* in the end, the consumer has to try to know for sure, but if there is something like nixos-19.03/some, then the user might probably be able to guess that it's not going to work with master | 20:37:44 | |
In reply to @fufexan:matrix.orgSo this would be completed as: final: prev: { winestreamproxy = ...} | 20:38:26 | |
In reply to @fufexan:matrix.org* So this would be completed as: "nixpkgs/winestreamproxy" = final: prev: { winestreamproxy = ...} | 20:38:43 | |
| As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a spearate overlay. | 20:39:38 | |
| * As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a separate overlay. | 20:39:44 | |
* As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a separate overlay. A good example would be if you manage a single overlays.nix file with all your overlays defined according to your personal needs. A consumer might want to pick one out of these. | 20:40:46 | |
* As an author, you probably group some overlays together. But that doesn't mean as a consumer you want to be forced to consume the entire group. That's the reason why each overlay attribute is put in a separate overlay. A good example would be if you manage a single overlays.nix file with all your overlays defined according to your personal needs. A consumer relatively likely might want to pick one out of these. | 20:40:54 | |
| In you well-crafted example, this splitting does not make a lot of sense and the overlay could / should be consumed as a whole. I think we can't have enough guarantees that overlays will always be well crafted though, so we have to sort of put that burdon on the consumer. | 20:42:52 | |
| At least, that's my currently best answer to the problem. But probably it's not the last? | 20:43:11 | |
| * In you well-crafted example, this splitting does not make a lot of sense and the overlay could / should be consumed as a whole. I think we can't have enough guarantees that overlays will always be well crafted though, so we have to sort of put that burdon (of managing overlay dependencies) on the consumer. | 20:43:59 | |
| I see the problem 😄 | 20:45:35 | |
| this makes sense, thanks for the thorough explanation! | 20:45:41 | |
| ... but not in your case with the well crafted overlay. Let's see for a while if we need to come up with a better solution. | 20:46:14 | |
| what I wanted to split the overlay for was, I have it in this repo but I want to import
| 20:48:18 | |
now I'm not sure if callPackage is the way to do this, but it seems to work with neither that nor import ... {} | 20:48:56 | |
| Overlays would have to be applyed, then the packages are avaliable as usual. Something like:
| 20:55:10 | |
| * Overlays would have to be applyed, then the packages are avaliable as usual. Something like:
| 20:55:16 | |
| * Overlays would have to be applyed, then the packages are avaliable as usual. Something like:
| 20:55:28 | |
| 😲 that makes sense | 20:55:32 | |
| I haven't thought of that | 20:55:37 | |
Beware, the order of overlays is important. so wine-tkg overlay would have to go before winestreamproxy overlay | 20:56:16 | |
| * Overlays would have to be applied, then the packages are avaliable as usual. Something like:
| 20:57:10 | |
| * Overlays would have to be applied, then the packages are available as usual. Something like:
| 20:57:18 | |
| now
| 21:00:21 | |
| oh wait not this one | 21:00:47 | |
| okay it seems like it was that one | 21:01:34 | |
when using nix flake (pure by default) builtins.currentSystem, as an impurity, is not available. | 21:01:39 | |
* when using nix flake (pure by default) builtins.currentSystem, as an impurity, is not available. | 21:01:46 | |