Missing file when the path is taken from a dhall `env`

[PierreR]

Given this source: https://github.com/PierreR/dhall-packages/blob/master/openshift/examples/cron1.dhall#L1

dhall-to-yaml --file openshift/examples/cron1.dhall --output openshift/examples/cron1.yaml

↳ env:OC ↳ ../package.dhall sha256:5c0bd30ac3c1d0914770754fe82256720a04471f38a26bbc6b63bd7ebd9eea94

Error: Missing file ../package.dhall

This does not seem to make sense because if I replace env:OC with ../package.dhall sha256:5c0bd30ac3c1d0914770754fe82256720a04471f38a26bbc6b63bd7ebd9eea94 within the file, it works.

As soon as I do the replacement if I replace back to env:OC then the error message disappears which is pretty confusing.

I have witnessed this behaviour both with 1.33 and 1.34 with multiple files.

This is not such a big deal. I can remove the usage of the env variable for now for local files (and use dhall freeze to regenerate the hash on all the files).

As a note the usage of an env works without problem with URL (for instance export OC='http://stash.cirb.lan/projects/CICD/repos/dhall/raw/openshift/package.dhall sha256:0e0285ed2307dcc88e89f5d44720fcbac1d97fa2ed953c2fb12f2fa0514184a1').

[Gabriella439]

@PierreR: This is a case where the language standard is underspecified, but I can at least explain why the Haskell implementation behaves this way.

It's because relative imports like ../package.dhall are resolved relative to their parent, and if the parent is an environment variable import then the import is relative to the present working directory. The reason the import works when you remove the environment variable intermediate is because then the parent of the import is the file it was imported from, so the relative import works correctly.

What I think is the correct solution is to change the standard's referential sanity check to forbid environment variables from transitively importing relative paths. That way you would have gotten an error message instead of confusing behavior.

[PierreR]

@Gabriel439 Thanks for the clear explanation.

What I think is the correct solution is to change the standard's referential sanity check to forbid environment variables from transitively importing relative paths. That way you would have gotten an error message instead of confusing behavior.

Sounds good to me.