Dhall-lang: Package manager for dhall

[RyanSiu1995]

As the community grows, does dhall have any plan on creating a package manager, like hex and mix does?
In my current development, the configuration based on dhall highly relies on the git submodule to import the preconfigured script like dhall-k8s.
The package manager just standardize the schema on specifying the dependency information with a dhall file, maybe simply call it project.dhall.
Then, there will be executable to clone the scm and checkout the corresponding commit.
I do believe such package manager help the developer a lot in doing stuff wit dhall! And more developers are willing to explore dhall as well!

[f-f]

Hi @RyanSiu1995!

I believe Dhall's need for a package manager is not as acute as other programming languages. The reason is that one of Dhall's features is "remote import resolution", that together with "hash protection on imports" makes for an excellent built-in "package manager"

For example, let's say you have this expression in your repo:

let Deployment = https://raw.githubusercontent.com/dhall-lang/dhall-kubernetes/4a904b46883c9894f887d9e5928930175892d6f8/types/io.k8s.api.apps.v1.Deployment.dhall sha256:5073ded75bc6715d954d7b102ad3663d0adc6c240335514876396dffe7a779e4

in Deployment

When you run this expression locally, Dhall will:

• fetch that Deployment type from a specific commit of the dhall-kubernetes repo
• verify that the file still matches the hash
• cache the result locally, so that the next time you require this import there will be no network activity

This is not that different from what a package manager does (i.e. require specific version of a piece of code, check for integrity, eventually cache it)

In fact, Dhall makes for a good substrate for package managers in other languages too.
E.g. spago is a PureScript package manager that uses Dhall to resolve package definitions in a similar way as described above.

[RyanSiu1995]

While I develop the tools based on dhall pre-defined script, like prelude, it is annoying that I need to wait for the file getting for those files. Maybe I think dhall itself can enable the cache so the development time can be shortened?

[Gabriel439]

@RyanSiu1995: If you protect the Prelude import with a semantic integrity check then it should only be fetched once. For example, suppose you have this file, which refers to the Prelude:

let Prelude =
      https://raw.githubusercontent.com/dhall-lang/dhall-lang/v6.0.0/Prelude/package.dhall

in  Prelude.`Bool`.not True

You can use dhall freeze to automatically pin and locally cache the Prelude import for you:

$ dhall freeze --inplace ./example.dhall

... which produces this:

let Prelude =
      https://raw.githubusercontent.com/dhall-lang/dhall-lang/v6.0.0/Prelude/package.dhall
        sha256:e3be3dba308637ad7ab6d4ce9a11a342b087efbf2aa801c88a05a6babaae8e48

in  Prelude.`Bool`.not True

... and then the Prelude reference resolves instantly when you interpret the file:

$ time dhall <<< './example.dhall' 
False

real    0m0.040s
user    0m0.022s
sys 0m0.010s

Also, if you interpret that same ./example.dhall file on another machine that does not yet have the Prelude cached, the interpreter will automatically cache the Prelude the first time that user interprets the file. That means that the second interpretation of the file on any machine will always be a cache hit for the Prelude.