-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find a good solution for bloated lock files #111
Comments
This sounds like a really good solution for keeping the scope of private flakes in check. Should we have a strict semantic for what can be in the |
I would look at these as drop-in for Instead of: {inputs, cell}: {} We may get something like: {
inputs = { /* ... */ };
outputs = inputs: {
/* ... */
};
} I'm currently thinking that in this case, we'd have to forgo the But this looks like in need for more thought... Or: we could assume that the parts that depend on Another open question would be: how to deal with |
I was thinking we would just restrict these flakes to re-exporting there inputs so that |
That could be a good idea, however, it would o ky cater the locking case, it wouldn't open the door to independently consume that subflake. But then again, consuming that subflake creates still other issues, which we might not want to incur in a first step. |
This is another good data point: Used here |
Coming back to this, I think having organelle local flakes is a bit too ganular, after all, it is the cell that is meant to be a logical collection of related code segments, so I'm thinking that private flakes would potentially be better at the cell level. |
I've recently been wondering if this doesn't introduce prohibitive accidential complexity (as introduced by Fred Brooks' 1987 paper No Silver Bullet) at comparatively little gain? An optimization that concerns the layout and contents of a machine-written & -read file, might be accidential complexity outside of the actual serializer / deserializer domain. And so are readability aspects for the human eye as a secondary consumer of that file. On the other hand, unrelated inputs (bloat) that are not adequately abstracted away have a cost and cause accidential complexity all by themselves. I have a sense that we should wait to see which path upstream takes for the first problem, before we tackle the second. Or at least, we shouldn't try to solve the first problem, here (serializer/deserializer domain is out of scope for Standard), but, if so, then only the second. I don't want to be misunderstood: I acknowledge that either way this solves problems that ought to be solved. |
Well I agree, there is a reason I tried to bring this up upstream first via discourse. Perhaps an actual issue on the Nix issue tracker would be warranted as well. I'm just saying, since we are using flakes in production now, we have a pathway to solve this right now in a way that is well defined. |
|
Out of the frustrations described and linked in : https://discourse.nixos.org/t/private-flake-inputs/21277
cell/organelle/flake.nix
callFlakeWith
functionsNow, that subflake can specify local ("private") inputs that are of rather scoped character. The toplevel flake's lockfile is kept down, in fact any lockfile is kept down, being nicer to downstream users.
This also may facilitate the self-referential conundrum in mono-repo settings with unbound flake growth.
@nrdxp
The text was updated successfully, but these errors were encountered: