Imports relative to the file that's importing

[dhall-lang]

Imports relative to the file that's importing

[ocharles]

There is a natural question about what this means for HTTP imports - that is, what does it mean to be "relative" to a HTTP import. One solution is to simply prohibit it, the other option is to build a path relative to the HTTP URL. It could be argued that a relative import from a HTTP import is unsafe though anyway, as it has the ability to import things from the local fs, which could be used to accidentally expose potential secrets.

[Gabriella439]

@ocharles: Note that the example works if you instead do:

$ dhall <<< './a/b`

The only reason it failed was because you fed ./a/b through standard input so Dhall doesn't know what where standard input is coming from, so Dhall assumed it was relative to the current directory by default.

Also, Dhall does handle paths relative to HTTP imports. For example, if you import http://example.com/foo/bar and then that imports ./baz then the relative import will resolve to http://example.com/foo/baz

HTTP imports cannot import things from the local filesystem (of either the server or client). For example, if the http://example.com/foo/baz import tried to import an absolute path like /baz then the import would fail with a ReferentiallyOpaque exception. Same thing for environment variables: remote imports cannot reference environment variables. More generally, there is a check that anything remote cannot import anything local. See:

https://github.com/dhall-lang/dhall-haskell/blob/0257e860466249f027bf1266c458239184e613d0/src/Dhall/Import.hs#L203-L228

https://github.com/dhall-lang/dhall-haskell/blob/0257e860466249f027bf1266c458239184e613d0/src/Dhall/Import.hs#L786-L795

dhall-lang/dhall-haskell#162 (comment)

[Gabriella439]

This is also why I want to finish standardizing the semantics because the last thing to standardize is the import semantics, which includes details like this

[ocharles]

Ohhhh, that makes sense. I was surprised when I saw an imported file import another file, then it did what I wanted. This all sounds sane to me, think this can be closed. On 14 Jan 2018 3:41 pm, "Gabriel Gonzalez" <[email protected]> wrote: @ocharles <https://github.com/ocharles>: Note that the example works if you instead do: $ dhall <<< './a/b` The only reason it failed was because you fed ./a/b through standard input so Dhall doesn't know what where standard input is coming from, so Dhall assumed it was relative to the current directory by default. Also, Dhall does handle paths relative to HTTP imports. For example, if you import http://example.com/foo/bar and then that imports ./baz then the relative import will resolve to http://example.com/foo/baz HTTP imports cannot import things from the local filesystem (of either the server or client). For example, if the http://example.com/foo/baz import tried to import an absolute path like /baz then the import would fail with a ReferentiallyOpaque exception. Same thing for environment variables: remote imports cannot reference environment variables. More generally, there is a check that anything remote cannot import anything local. See: https://github.com/dhall-lang/dhall-haskell/blob/ 0257e860466249f027bf1266c458239184e613d0/src/Dhall/Import.hs#L203-L228 https://github.com/dhall-lang/dhall-haskell/blob/ 0257e860466249f027bf1266c458239184e613d0/src/Dhall/Import.hs#L786-L795 dhall-lang/dhall-haskell#162 (comment) <dhall-lang/dhall-haskell#162 (comment)> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABRjqV2gvSGUfWlv7kFLK6rG1fsyuXCks5tKiA6gaJpZM4RdnMG> .

[Gabriella439]

You're welcome! :)

[Profpatsch]

That was the reason I added dhall-lang/dhall-haskell#190.
It’s a bit confusing that stdin doesn’t have a file context (all the while dhall doesn’t allow for a filename as import). Right now I don’t have a strong opinion yet on whether a --file flag or similar should exist, but playing further with evaluating dhall expressions in nix builds might change that.

Also awesome trick with dhall <<< './a/b', didn’t think of that.