Distinguish different types of Nix paths at the type level #172
Conversation
|
Any chance for a review? |
|
Sorry for leaving this. I think it would be better to create a single |
|
Ah, but having the single NODE_PATH parent would make it more annoying to distinguish the kind of the entire path. |
|
Yeah :) Note that once this is merged I'll update https://cl.snix.dev/c/snix/+/30323 |
|
@oberblastmeister so let's keep it as is or do you think we should have |
|
I think we can keep it as is. Maybe we can create an enum for the path nodes using the |
domenkozar
force-pushed
the
path-types
branch
2 times, most recently
from
2af4cea to
fff5eb1
Compare
- Added distinct token and node types for different path varieties: - PathAbs: Absolute paths starting with `/` (e.g., `/nix/store/...`) - PathRel: Relative paths (e.g., `./foo`, `foo/bar`) - PathHome: Home-relative paths starting with `~/` (e.g., `~/foo/bar`) - PathSearch: NIX_PATH expressions (e.g., `<nixpkgs>`) - Created `InterpolatablePath` trait for paths that support interpolation (all except search paths) - Added helper methods to path content for easier path type checking and access through `match_path`, `is_search`, `is_interpolatable`, etc. This allows code to determine what kind of path it's dealing with without having to re-parse the path string, improving type safety, correctness, and making path-specific operations more explicit.
|
@oberblastmeister thanks, I've done that and implemented a hierarchy of traits on top of it to extract parts of the path out :) |
#166
I'm not entirely sure about the special casing for UPDATE, there could be a better way?
cc @oberblastmeister