Execute Command "volta install node@latest" An error occurred "thread 'main' panicked at"

[baiyajin]

trafficstars

C:\Users\Administrator>volta install node@latest thread 'main' panicked at C:\Users\runneradmin.cargo\registry\src\index.crates.io-6f17d22bba15001f\attohttpc-0.28.0\src\request\builder.rs:54:41: invalid url or method: Error(InvalidBaseUrl) note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

[silky]

Thanks for making this issue :)

I'd honestly be happy/expect to see this pop up when running adding some verbosity to the commands; it's what I tried to do to debug the issue, and was left confused when additional v's didn't yield me any particularly relevant hints ....

[Kha]

Relevant: https://github.com/NixOS/nix/pull/6858#issuecomment-1203872793 and following comments

[squalus]

For anyone else running into this, here's how to include untracked files: nix build path:///path/to/myflake#mypackage.

The entire flake directory gets copied to the Nix store in this case.

[Atemu]

With https://github.com/NixOS/nix/pull/6530, the problem of accidentally copying large untracked files should no longer exist.

I think it'd make sense to disable the unintuitive git integration then.

I'm all for integrating different tools with another but that should always be an optional feature. A build tool should not care about which VCS I'm using or what its state is; especially not by default. (Being able to fetch a build expression via git is a great feature though.)

[andrewhamon]

I too was pretty surprised at the tight git integration, and it makes certain things impossible, like conditionally importing an untracked file that may or may not exists (i.e. poor mans secret management, or a way to let folks customize a nix shell in a large shared repo).

[silky]

Depending on your setup @andrewhamon you might be interested in something like this - https://github.com/hasura/graphql-engine/blob/master/.envrc#L59 - to source a local .envrc file.

[bergkvist]

Even being familiar with this behavior, I find it cumbersome/unintuitive, and it is one of my biggest barriers to moving from traditional nix over to flakes.

What if instead of using the git staging area, there was a .flakeignore, similar to .dockerignore/.gitignore? I think this would be a lot more intuitive to new users, and could provide similar benefits in a more flexible way.

It might also be a step towards decoupling nix flakes and git - such that companies that use alternatives to git for version control would actually be able to adopt flakes as well.

[outfoxxed]

It is also extremely frustrating on nixos with direnv for development environments, where the project does not need or want the flake in version control. I have to remove the nix files from git, commit, and re-add them. The only reason for these flakes to exist is to set up my local dev env.

[tejing1]

Could nix by default use path:. instead of git+file:. when flake.nix is untracked and/or gitignored? It would at least streamline the local-only flake.nix usecase.

[ryanalta]

Being newish to nix and flakes I'm definitely in the user group of of 'unaware users'. One problem I run into is that I might want a .env in the development shell, but definitely don't want to track in git (it's in my .gitignore so I don't accidentally add, commit and push it).

I'm not sure what the best practice is for this with flakes, but my first guess of having an .env file in the directory with flake.nix appears to be wrong.

[mwotton]

I think the behaviour is right, but some breadcrumbs in the error message about it being potentially related to source control would be very much appreciated.

[1oglop1]

It would be great to have a warning or hint if the local file is untracked. It is my second day of learning nix and this behaviour is quite confusing. Because the problem with untracked files appears only inside the git repo which I have not initialized for small learning projects, then after progressing towards a more real project I kept getting the error No such file or directory and it took me some time to realize that it may be an untracked file.

[agraven]

Another factor that exacerbated the confusion for me is that this behavior also aplloes wheb you are in an ignored subfolder of a repo with a root higher up the tree. I sync my dotfiles by making my $HOME a git repo, so when i went into my projects directory and attempted to create a flake with nix flake init, it failed to build with an extremely unhelpful "No such file or directory" error that provided zero indication what the actual problem was.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/weird-missing-nix-store-when-running-a-home-manager-rebuild/37898/2

[fwcd]

My mental model is that Nix, like most other package managers, should operate independently from any particular source control and, if needed, implement its own ignore mechanism, as suggested by @bergkvist. Having to add/commit files to avoid having the packages silently be left in an inconsistent state has tripped me up several times now.

[eclairevoyant]

Having to commit files

Reminder that you do not need to commit anything. git add -N is sufficient if you don't want to stage the changes yet.

edit: thumbs down notwithstanding, my statement is still correct.

[codingCoffee]

I'm using an .env.nix file for storing variables which I do not want committed into my repo. And I'm importing this file into configuration.nix to use it. I've gitignored the .env.nix file. Now when running nixos-rebuild switch the nix store does not copy / symlink my .env.nix file into the nix store, thereby raising the error No such file or directory.

If I'm not using a git repo, things work flawlessly. Having everything in a git repo causes issues.

Any solution to this pattern of usage!?

[mightyiam]

I'm using an .env.nix file for storing variables which I do not want committed into my repo. And I'm importing this file into configuration.nix to use it.

This might be an impurity.

[tejing1]

Any solution to this pattern of usage!?

If you refer to path:.#output instead of .#output, I believe it should consider the directory itself, without regard to git. That has its own problems however, such as that the entire directory contents, including the .git directory, will be copied to the nix store, which could get rather inconvenient.

At a basic level, what you're trying to do is somewhat contrary to the intention of flakes. Flakes are supposed to contain and lock every input to a given result, without exception, and you're trying to carve out an exception.

[codingCoffee]

This might be an impurity.

Flakes are supposed to contain and lock every input to a given result, without exception, and you're trying to carve out an exception.

Duly noted. Will figure out a way to better manage secrets. sops-nix or agenix come to mind.

[DaniD3v]

Wanted to comment that I just spent like 3 hours wondering why my modules folder including my home-manager configuration didn't get copied into the nix store. The lack of documentation doesn't exactly help that. Maybe add a tip to the error message of nix not finding files in store paths.

Also this is kinda annoying for my secret management but the workaround with path:// mentioned above fixes this.

I think we should have a .flakeignore or something. This behavior is counterintuitive and can throw really confusing erros

[JeffLabonte]

Could nix by default use path:. instead of git+file:. when flake.nix is untracked and/or gitignored? It would at least streamline the local-only flake.nix usecase.

Well, using :path. instead of . fixed my problem. Thank you!

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/path-nix-store-does-not-exist/55413/4

[jwdevantier]

Just to point out. it is path:<flake-ref> not :path<flake-ref>, aside from that, it does fix the issue.

I just want to point out also that this STILL happens even if operating in a sub-directory which is explicitly ignored by .gitignore. I think this is deeply unintuitive, and does more harm than good.

Why would you have files in an ignored directory, you ask ? For example, you may be generating these configuration files - and there might be good reasons for that.

[Ev357]

I'm sure that there is a good reason for this behaviour, but maybe an option to disable this for quick testing?

[eclairevoyant]

A dozen workarounds have been mentioned upthread e.g. https://github.com/NixOS/nix/issues/7107#issuecomment-1883510675 and https://github.com/NixOS/nix/issues/7107#issuecomment-2002363048, can this not become a support thread asking the same questions repeatedly?

[brbsleepy]

hello, i just stepped on this rake.

redirected from the helpful people here: https://discourse.nixos.org/t/path-nix-store-does-not-exist/55413/2

i'd love to see some mention of git tracking in the error message

[sleroq]

Having to commit files

Reminder that you do not need to commit anything. git add -N is sufficient if you don't want to stage the changes yet.

edit: thumbs down notwithstanding, my statement is still correct.

Thank you for the git add -N tip.

To add to that, for not committing files by accident, I use git update-index --skip-worktree <your-file>. So, it won't even show up as modified when you go to commit.

And you can add it to your Nix dev shell if you want to make it automatic for all contributors.

Hope this helps someone to not commit private info to GitHub.

[non-bin]

Just spent half an hour debugging because of this, I'm a seasoned nix user and I just forgot. I don't think it would be hard to add a check like this:

if (!exists('git+file:'+filePath) && exists('file:'+filePath)) {
  print('Did you forget to stage '+filePath+'?');
}

It might involve making a list of untracked files during pre-build and keeping it around in case of an error. Maybe I'll take a look sometime

[gauravjuvekar]

It seems like there is a related recent regression, though I haven't been able to bisect it to an exact nix commit yet.

Observed: If your .git points to a different directory gitdir: /some/other/path, then nix behaves as if the repo was not updated even if changes are staged / committed. Adding --refresh to the nix command line fixes that.