Dhall-haskell: dhall resolve doesn't respect relative directories

[FintanH]

Working off of d1e8fde9c081122147db5cf443f7651c0430d71a

Directory structure:

.
└── test
    ├── dub
    └── num

dub

{ dub : Double }

num

{ num : ./dub }

Error

Running dhall freeze --inplace "./test/num" the following error is produced:

↳ ./dub

Error: Missing file /home/fintan/Developer/test-freeze/dub

EDIT

Actually this isn't really freezes fault. This is down to resolution.
Running cat ./test/num | dhall resolve we get the same error as above

[f-f]

Oh, thank you for opening this 👏
I discovered roughly one month ago that we have the same issue with dhall-kubernetes (e.g. this file) but I totally forgot to open an issue about it.

[FintanH]

@f-f Heh, for sure! I'm gonna try fix it now. We want to get caching working so first step is to get freezing working :grin:

[FintanH]

Seems that the import is using Local Here for some reason:

Import {importHashed = ImportHashed {hash = Nothing, importType = Local Here (File {directory = Directory {components = []}, file = "dub"})}, importMode = Code}

[FintanH]

It seems that loadWith doesn't realize we've gone an extra directory down the tree.

[FintanH]

I'm starting to realize the underlying issue here. So when we do cat ./test/num | dhall resolve the cat turns the expression into { dub : ./dub }. Then dhall resolve sees ./dub and assumes it's in the same directory as the call. This isn't the case so we've lost information. I think this is the correct behavior. The INCORRECT behavior is loading the file when doing the freeze so I'll try go down that route to fix this :smile: #rubberducking

[f-f]

@FintanH this is my reproduction case:

 $ dhall freeze --inplace examples/deployment.dhall

↳ ./../api/Deployment/default

Error: Missing file /Users/fabrizio/code/dhall-kubernetes/../api/Deployment/default

Where this is the file I'm trying to freeze, and it imports the file ../api/Deployment/default on the second line.

Note that if you do dhall <<< "./examples/deployment.dhall" then all is well.

EDIT: of course if you do cd examples && dhall freeze --inplace deployment.dhall then it works properly.

So the issue is the same one that you're describing in your last comment: what freeze is doing here is not right

[FintanH]

@f-f Can you try use https://github.com/FintanH/dhall-haskell/tree/fintan/fix-freeze and see if it works for you? Make sure to have a copy just in case :grimacing: Also it seems it needs to be ./example/deployment.dhall. Need to figure out why it needs that relativity

[f-f]

@FintanH tried the branch:

• if I don't specify the ./, it nukes the file
• if I do specify it, then it replaces the content with an import to itself, protected by some sha 😄

[FintanH]

I think the second point is actually what we want, right? Because if you run it through dhall it loads it from the cache. @Gabriel439 can you confirm?

[f-f]

No, that would lose whatever content is in the file, so I cannot edit it anymore, ever.
What freeze should do is: replace any import inside a file with the same import with a hash attached to it (this is also the current behaviour on master)

[FintanH]

Ahhhh right. I'll get on it :joy:

[FintanH]

I need some way of forcing only one level of resolution so that I can then walk the imports in the input file :thinking:

[Gabriel439]

@FintanH: In the Haskell REPL you can do traverse exprFromImport since an Expr is Traversable

[FintanH]

Thanks, I'll give it a look tomorrow :ok_hand:

[FintanH]

I was taking a look because of obsessive brain. I'm not sure I can come up with a solution using what's already there. I think some functionality akin to the Dhall.Import functions might be needed.

[Gabriel439]

Fix up here: https://github.com/dhall-lang/dhall-haskell/pull/619

[Gabriel439]

Also, note that this is not an issue with import resolution per se. For example, dhall < ./foo/bar has intentionally never correctly resolved imports relative to ./foo/bar correctly because it can't know that standard input came from that file path (or that it even came from a file at all). This is why you always should do dhall <<< './foo/bar' instead. See:

https://github.com/dhall-lang/dhall-lang/wiki/Frequently-Asked-Questions-(FAQ)#imports-relative-to-my-top-level-file-are-not-working

[FintanH]

Ya, I realized this after the face :flushed: Thanks for the fix!

[Gabriel439]

You're welcome!