[RFC 0017] Intensional Store #17
Conversation
rfcs/0017-intensional-store.md
Outdated
| Terms used: | ||
| * derivation: a `nix-build` output product depending on some inputs and resulting in a file or directory under `/nix/store` | ||
| * dependent derivation: a derivation built using the currently considered derivation | ||
| * `$out`: name of the location where a derivation is built, e.g., `zyb6qaasr5yhh2r4484x01cy87xzddn7-unit-script-1.12` |
There was a problem hiding this comment.
it should be mentioned that it's an absolute path
|
I wonder if this can already be (partly) implemented as a wrapper applied in |
|
Even if we only have a manual way of transforming a drv to CAS, it would already be useful and we don't have to make it work for corner-cases like when $out has references to $out. |
|
I think |
|
It would allow to break unnecessary coupling, for example here: A |
|
Sadly I don't have time to work on this right now, but I still definitely
want to do it. I already prototyped it a bit when I originally posted it,
and it didn't make a huge difference but it does make a difference. My
approach will be to find where in Nix the checksum calculations are done,
implement a version that ignores the own path, and then see where that
leads me.
…On Sun, Nov 5, 2017 at 7:33 PM zimbatm ***@***.***> wrote:
It would allow to break unnecessary coupling, for example here:
https://github.com/moretea/yarn2nix/blob/ebde7ffe0f515900d591a9786d29898d5cea63bb/default.nix#L102-L104
A src is given which is written to the /nix/store. Then helpfully we
deduce the package.json from that src. But because the src store path
will change if any of the files have changed, the package.json reference
will also necessarily change and create unnecessarily rebuild of the
node_modules.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AADWloETYRSpLbOafvayeMebm7cOepKnks5szf94gaJpZM4O1LHU>
.
|
|
Do you think that there is a way to implement a prototype that doesn't require a new nix builtin? |
|
Hmm sure, to get an idea, yes. It won't actually help builds or hydra but
it will give an idea of what the store will look like. Although the
prototyping I did on nix-dev already gave a good insight into that…
…On Sun, Nov 5, 2017, 10:00 PM zimbatm ***@***.***> wrote:
Do you think that there is a way to implement a prototype that doesn't
require a new nix builtin?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AADWlvgmr-En2f8MjEcbcfEJfMePqTrlks5sziIAgaJpZM4O1LHU>
.
|
self-references may not be discoverable by grep
|
I’d like to contribute to this, but not quite sure where to begin. |
|
@wmertens We're doing triage on the backlog of open RFCs. Are you still interested in pursuing this RFC? BTW, I made a bit of progress towards content-addressable stores: edolstra/nix@a4d0a11. It doesn't support automatically moving derivation outputs to content-addressable locations yet, though. |
|
Yes, I still think it will be a valuable addition. What is the next step?
Wout.
…On Thu, Jan 17, 2019 at 12:05 PM Eelco Dolstra ***@***.***> wrote:
@wmertens <https://github.com/wmertens> We're doing triage on the backlog
of open RFCs. Are you still interested in pursuing this RFC?
BTW, I made a bit of progress towards content-addressable stores:
***@***.***
<edolstra/nix@a4d0a11>.
It doesn't support automatically moving derivation outputs to
content-addressable locations yet, though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AADWlplnljIm0VW5S-aVD-hSznsXVUEbks5vEFjwgaJpZM4O1LHU>
.
|
|
The next step is to get an RFC shepherd team. @globin I think you said you would open it for nominations? |
|
I am interested in this. |
This comment has been minimized.
This comment has been minimized.
|
I'd like to nominate @vcunat and @fpletz for NixOS/nix#859 and https://github.com/orgs/NixIPFS/people |
|
I'd like to nominate @edolstra and myself for the shepherd team |
|
Yes, I'd like to review the design for (future) "intensional store", regardless of getting into the team. |
|
Before reviewing the details, I do have one high level concern. To quote from the README:
Assuming this does get accepted, do we have someone ready to implement it? Changes this deep to the store model involve a significant amount of work, I'm a bit worried about this RFC getting approved but no one implementing it for a long time, at which point many of the considerations that go into the current design may have changed drastically. |
|
@shlevy I wonder if it would be a good idea to try making a survey of what parts are currently available (even before answering your question, maybe) |
|
I nominate @nbp |
|
What's the status of this RFC? What are the blockers, and what needs to be done to make this RFC happen? |
* 166: Nix formatting Create 0101-nix-formatting.md WIP Go through a large part and agree on it Co-Authored-By: @piegamesde Update 0101-nix-formatting.md Rework a lot of things Update 0101-nix-formatting.md Move around some sections Reword the detailed section Minor updates Slight header changes again Updates Update 0101-nix-formatting.md Update after today's meeting Update 0101-nix-formatting.md Further updates in the meeting Update 0101-nix-formatting.md After todays meeting Update after meeting Rename to probably the right number Only use anchor links Improvements and additions - The sub-expression rule is now reworded and its own section with examples and rationale - Line length limit is now specified as we agreed-upon in the meeting - The operator section is rewritten to align more with the consensus Redo and explain operator special case Also remove the special case for non-chainable operators, barely any benefit in Nixpkgs * Operator chains outside bindings can also have a compact form * Make the operator compact form specific to binders * Fix accidentally formatted semicolons in alternatives * Minor changes * Light copy editing * Fix .git-blame-ignore-revs * Improve assert/with wording * Be more flexible with single-line element count * binder -> binding * unindent inherit semicolon, reshuffle binding/inherit sections (#14) * unindent inherit semicolon, reshuffle binding/inherit sections * fixup! Stuff * Give alternatives to `in` formatting * Expand on line break preservation * Add editorconfig * Expand argumentation against leading commas * Add @dasJ to the formatter team * Add shepherd team Co-authored-by: Linus Heckemann <[email protected]> * Various improvements (#15) * Various improvements - Remove unnecessary **Description** headers - Rename **Rationale and Alternatives** to just **Alternatives** - Insert must/may/should more diligently - Add some TODOs where things are unclear - Remove numberings from examples when not needed - Minor clarity improvements and simplifications throughout * Apply suggestions from code review Co-authored-by: Ryan Hendrickson <[email protected]> --------- Co-authored-by: Ryan Hendrickson <[email protected]> * Address TODOs and rework with/assert * Minor adjustments * Mention formatting Nix code in documentation * Working towards finalization (#16) - Defined absorption and absorbable terms - Adapted the existing RFC text to make use of these definitions, resulting in simplications of the text in many cases. - Updated `with` section to match the implementation - Updated the function declaration section to match the implementation - Sometimes, the function body may get absorbed - This used to be a special case scoped to bindings only, so it got removed there - Updated the operators section to match the implementation - Specify the format of non-chainable operators (somehow those got lost in the past) - Reworked bindings section. It should now be clear and specific enough. - Minor wording fixes * String section * Specify assert conditions * More absorption for multi-line arguments * How to update the standard format * Fix minor typos * Less lines for common function call patterns * Specify comments * Specify that the formatter should be as pure as possible With some exceptions * nit: fix list concatenation example (#17) * Update rfcs/0166-nix-formatting.md Co-authored-by: Doron Behar <[email protected]> * Add good indentation examples (#18) * Add another chainable operators example * justify difference in semicolon placement * Allow different parenthesized argument style * Clarify non-vertical alignment rule * Improved clarity of bindings rule * Improve bindings semicolon alternatives section --------- Co-authored-by: Silvan Mosberger <[email protected]> Co-authored-by: Silvan Mosberger <[email protected]> Co-authored-by: Ryan Hendrickson <[email protected]> Co-authored-by: Yuriy Taraday <[email protected]> Co-authored-by: Linus Heckemann <[email protected]> Co-authored-by: Janne Heß <[email protected]> Co-authored-by: Doron Behar <[email protected]>
|
I can understand that efforts have been diverted these last few months for various reasons. That being said, is there still an appetite to move this RFC forward, and what are the next steps? |
This RFC builds on the implementation of RFC #62 to maximize its benefits.
/var/lib/nixfor better compatibility with other platformsnix-daemonbecomes optionalRendered