feat: open terminal links for store paths in workspace #275
Conversation
no sure how to test, but seems like good solution |
I generally just press |
src/extension.ts
Outdated
| @@ -5,6 +5,12 @@ import { startLinting } from "./linter"; | |||
| import { config } from "./configuration"; | |||
| import * as client from "./client"; | |||
|
|
|||
| const storeRegex = /\/nix\/store\/.{32}-[^/]*\/([^:]*)/g; | |||
There was a problem hiding this comment.
can we make this store-path a configurable value?
There was a problem hiding this comment.
may there is already nix env variable or nix conf file having the path? so when you run nix you run from that path and may be extensions can access it?
There was a problem hiding this comment.
There's NIX_STORE_DIR; we could check that and then fallback to /nix/store.
|
Marking as draft b/c I haven't done any semi-serious testing yet. |
|
Yep, need a better determinator than "file exists in workspace" because, of course, there's going to be similarly-named files across unrelated derivatives; for example, this flake {
outputs = { self, nixpkgs, ... }@inputs:
let
system = "x86_64-linux";
pkgs = nixpkgs.legacyPackages.${system};
in
{
packages.${system}.default = pkgs.callPackage pkgs.hello { };
};
}throws the following error: which would open My first thought is that the local derivation is always called |
|
in rust, rust analyzer expands procedural macros and builds rs scripts. just to name something which doing ide level evaluation and expansion. nix is lazy and side effect free. so it can be evaluated, including each src. actually flake check and nix show doing something like that. so the only final fix is to evaluate whole tree. dump it to json. and use as virtual file tree. will donate 10 DOT for such solution. but can with current only root solution is ok if to provide not nix store config, but config for current root src. i can just make my root src to be in subfolder i need. so for most people in simple projects it will work without modification. choose src or file from multiple on click does not feel good to go. so current solution with env var for store location and per workspace src configuration can be great. |
oh. that is bad. ruins everything. so it needs evaluation of nix tree and deep integration with nix sql database. afaik nix is lazy strict dynamics. but when its is evaluated it is not so dynamic. so really this feature requires a step to real ide - building tree and linking it to "object" database. |
flake package, app does not work (we need app because we debug). but at least we see src |
so pretty sure it is there. but need to find out how to dump apps (likely flake also makes derivation of these). and then dump the tree. and then ls each src from that tree. and doing from time to time in background on inotify. |
|
i guess hydra CI/CD can do it to build DAG for workflows. |
|
not found, tried to search nix issues - no relevant. so seems like having such tools is going as deep into nix. |
|
so the problem is. if you run |
|
I'll have to dig more into that approach to understand it better; so long as it can work with both flake and non-flake project, it could work. As far as matching Some alternative approaches that come to mind:
|
|
I like showing the select dialog idea.
|
|
On flake.nix can run this Gives some output of all within flake.nix. Not sure if can built on this. May be ask |
These changes register a terminal link handler so that store paths can be handled as files relative to the workspace (if they exist in the workspace).
As it stands, this assumes the store is at
/nix/storeand that all paths are unix-style (which should cover most (all?) users but I can try to abstract those away if necessary).fixes #272