-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Combine AbstractPos
, PosAdapter
, and Pos
#9634
Combine AbstractPos
, PosAdapter
, and Pos
#9634
Conversation
cc @pennae who have optimized |
11ce214
to
4ac4d0d
Compare
we haven't reviewed this fully, but it seems like a good idea. |
src/libutil/file-ingestion-method.cc
Outdated
|
||
namespace nix { | ||
|
||
std::string makeFileIngestionPrefix(FileIngestionMethod m) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really want this sort of encoding thing to move from libstore
. it is an arbitrary choice of the store layer, not a reusable mechanism. If anything, I want to move this stuff out of content-address.{cc,hh}
and back down to the places where it is used (printing and parsing derivations, store paths) since it isn't really consistent between those two things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that InputAccessor
would have to expose a fingerprint, so that the rest of fetchToStore
can be moved back to libstore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, let me see how much of this I can move back to libstore
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I moved file-content-address.hh
and file-ingestion-method.hh
from libutil
to libstore
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I was unclear. I do want the enums themselves to live in libutil
. Those do belong with archive.hh
and source-accessor.hh
, which are also in libutil
. What doesn't belong is just the prefix string bits. The string prefix bits are not intrinsic to these concepts, and just relate to downstream concerns like derivation aterm and narinfo CA field.
If like, perhaps take a stab at #9278 ? The point of that issue to was to make precisely this sort of thing clear:
-
"File System Object" is a barely nix-specific notation, and that can stay in
libutil
(originally I proposed it go in a new library belowlibstore
also. -
"Store Object" is a very much nix-specific concept that should stay in
libstore
.
The prefix stuff in question have have a file system object name, but it is neither intrinsic to "file system object" or "store object". I should just push it down to the derivation / store path / narinfo serializations that need it. Serializations are intrinsic properties of data types being serialized, an indeed this colon-prefix stuff is no good and not not be used in the newer unstable JSON serializations. (It currently is, this needs to change.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The short version I that you can leave things the way they were prior to this PR if you like, and I'll at some future point I'll move this serialization nonsense out of content-address.cc
.
702b028
to
85d4a8d
Compare
9b53d24
to
a3caa8d
Compare
a3caa8d
to
f6eca16
Compare
@Ericson2314 Done, PTAL. |
OK thank you very much @9999years! |
@Ericson2314 Anything else left before merge? |
Nothing more from me on that stuff, but sure I should read over the rest. |
ee85359
to
e824cb8
Compare
src/libutil/repair-flag.hh
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be moved back, because fetchToStore
didn't move.
@9999years when you rebased/force-pushed you (I assume accidentally) undid the changes you requested that you make (shrinking the diff). |
https://github.com/NixOS/nix/compare/f6eca1696c98212879fa1ec9a84a5c985ce21b25..ee853597a8a8d2dcddf34bd347b2963ffe873206 this looks like the force pushed that force-push (second most recent) added-back the changes I requested you not do. |
Also move `SourcePath` into `libutil`. These changes allow `error.hh` and `error.cc` to access source path and position information, which we can use to produce better error messages (for example, we could consider omitting filenames when two or more consecutive stack frames originate from the same file).
e824cb8
to
4feb7d9
Compare
@Ericson2314 Nice catch, got that code restored correctly (I think). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @9999years! Sorry for the delay in the final review.
…-pos Combine `AbstractPos`, `PosAdapter`, and `Pos` (cherry picked from commit 113499d) === this is a bit cursed because originally it was based on InputAccessor code that we don't have and moved/patched features we likewise don't have (fetchToStore caching, all the individual accessors, ContentAddressMethod). the commit is adjusted accordingly to match (remove caching, ignore accessors, use FileIngestionMethod). note that `state.rootPath . CanonPath == abs` and computeStorePathForPath works relative to cwd, so the slight rewrite in the moved fetchToStore is legal. Change-Id: I05fd340c273f0bcc8ffabfebdc4a88b98083bce5
Motivation
Two big changes:
AbstractPos
andPosAdapter
intoPos
.SourcePath
intolibutil
.These changes allow
error.hh
anderror.cc
to access source path and position information, which we can use to produce better error messages (for example, we could consider omitting filenames when two or more consecutive stack frames originate from the same file, as in #9623).These changes are non-functional -- they do not change the behavior or user-interface of Nix.
All changes
Here's a list of all changes to types and methods in this PR:
Pos
fromlibexpr/nixexpr.hh
tolibutil/position.hh
PosAdapter
fromlibexpr/nixexpr.cc
AbstractPos
fromlibutil/error.hh
SourcePath
fromlibfetchers/input-accessor.hh
tolibutil/source-path.hh
fetchToStore
fromSourcePath::fetchToStore
andInputAccessor::fetchToStore
to a new filelibfetchers/fetch-to-store.hh
InputAccessor
fromlibfetchers
tolibutil
SourcePath
is aCanonPath
and anInputAccessor
, so this needed to be inlibutil
fetchToStore
removed, the class definition is very small and doesn't introduce any additional dependencies tolibutil
.makeFileIngestionPrefix
fromlibstore/content-address.hh
tolibstore/file-ingestion-method.hh
FileIngestionMethod
fromlibutil/file-content-address.hh
tolibstore/file-ingestion-method.hh
Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.