Skip to content

Allow relative paths in --store option#3736

Merged
edolstra merged 5 commits intoNixOS:masterfrom
obsidiansystems:allow-relative-paths-in-store-option
Jul 21, 2020
Merged

Allow relative paths in --store option#3736
edolstra merged 5 commits intoNixOS:masterfrom
obsidiansystems:allow-relative-paths-in-store-option

Conversation

@meditans
Copy link
Member

@meditans meditans commented Jun 23, 2020

In nix commands which accept --store options, we can now specify a
relative path, which will be canonicalized. The relative path must start
with ./ like in the nix language.

Fixes #3734

In nix commands which accept --store options, we can now specify a
relative path, which will be canonicalized.
@meditans meditans changed the title Allow relative paths in --store option WIP Allow relative paths in --store option Jun 23, 2020
@meditans
Copy link
Member Author

It works, but it's marked as WIP as some tests should be added for this.

if (uri == "daemon") {
return tDaemon;
} else if (uri == "local" || hasPrefix(uri, "/")) {
} else if (uri == "local" || hasPrefix(uri, "/") || hasPrefix(uri, "./")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might make sense to also allow . as a path

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cost of that would be divergence from the nix expression language though, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this already happens with cli args. for instance:

nix build -f . hello

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but does -f <url> work? Because we are overloading URL and relative path syntax, and URL syntax already is infamous for having parser mistakes/ambiguities/vulnerabilities, I rather move slowly. We can always add . later.

Of course, if @edolstra wants / there's concensus to go ahead and do ., we'll happily add it, but I rather advocate for the smallest change that gets the job done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

url's do work (although they have to be in tar format):

nix build -f https://github.com/NixOS/nixpkgs/archive/master.tar.gz hello

Copy link
Member

@matthewbauer matthewbauer Jul 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rules for it are:

Path lookupFileArg(EvalState & state, string s)
{
if (isUri(s)) {
return state.store->toRealPath(
fetchers::downloadTarball(
state.store, resolveUri(s), "source", false).first.storePath);
} else if (s.size() > 2 && s.at(0) == '<' && s.at(s.size() - 1) == '>') {
Path p = s.substr(1, s.size() - 2);
return state.findFile(p);
} else
return absPath(s);
}

Copy link
Member

@Ericson2314 Ericson2314 Jul 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK fair, but it as wrong of me to compare -f <url> in the first place, because this sort of "each store parses the thing" means having else cases is no good either---everything should be if (...) { ... } else return nullptr.

Now we could still do ., yes. My above does not work argument against that, I will totally grant.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edolstra's weak preference is if it doesn't contain :// and does contain / then it is deemed a path and is turned into a LocalStore.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In meeting we got @edolstra's preference, and I just updated the PR accordingly.

@meditans meditans force-pushed the allow-relative-paths-in-store-option branch from 8e5be0c to 4178f36 Compare July 17, 2020 19:51
@meditans meditans changed the title WIP Allow relative paths in --store option Allow relative paths in --store option Jul 17, 2020
The was Eelco's prefered logic, and it looks good to me!
throw Error("don't know how to open Nix store '%s'", uri);
}

static bool isNonUriPath(const std::string & spec) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you just use !isUri from file-transfer?

@edolstra edolstra merged commit ff314f1 into NixOS:master Jul 21, 2020
edolstra added a commit that referenced this pull request Sep 17, 2020
…te-regStore

Remove storetype delegate reg store -- contains #3736
@Ericson2314 Ericson2314 deleted the allow-relative-paths-in-store-option branch April 19, 2023 17:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

--store ./relative/path doesn't work

5 participants