Closed quasicomputational closed 5 years ago
Ah, it's the non-self-containment, and how it'll hit the network at runtime. A secondary problem is that it's mutable, so there's no guarantee that the Dhall being fetched will work with the user's version.
A third option occurs to me: we could run dhall resolve
at build time and distribute a 'statically linked' version of dhall/
, which has the benefit of clean source but also self-containment for users.
Ah, it's the non-self-containment, and how it'll hit the network at runtime
Only if it's not in the cache.
A secondary problem is that it's mutable, so there's no guarantee that the Dhall being fetched will work with the user's version.
That's just a case for versioning. We do have Git tag's that we should be using, and we should be using dhall freeze
to add hashes for caching compatibility.
Would that be sufficient?
I guess the cache is OK, though making sure it's filled is presently a bit clunky.
OK - let's go with HTTP; if it turns out to be a problem, there are always options.
I've done some further thinking, and I realised that HTTP doesn't necessarily mean hitting the network - it's imaginable that, e.g., Dhall will get clever enough that it'll be able to resolve HTTP imports by using provided signed HTTP exchanges. That it's liable to hit the network today, and preventing that relies on the vagaries of cache invalidation, is unfortunate.
Blocked on dhall-lang/dhall-lang#670, for version-pinned imports of the prelude from dhall-lang.org
.
Ah, and also on #179, because of that projection bug that was fixed in 1.25.
IMO, this is a function that highlights how
dhall-to-cabal
is an advance onhpack
: the best feature ofhpack
, settingghc-options
at the top level and then having them apply to all components without any per-component effort, is now really easy to implement. It was writable before the latest Dhall version, but record projection by expression turns it from horrible to just mildly repetetive.Tests are actually passing but I don't think its ready to merge on two counts:
dhall-lang/dhall-haskell#1009 means that, in
mapBuildInfo.dhall
, theBuildInfo
used as a field selector has to be an import. This hack is localised and could be noted for later removal and then merged, but...We'll want to work out what to do about the imports from Dhall's prelude. I don't really like the option of leaving them as HTTP URLs. Including the prelude as a submodule would be a bit awkward, not least because, as the files are extensionless, we can't use Cabal's wildcards to include them in
extra-source-files
. (haskell/cabal#5883 is the discussion on lifting that requirement.) Also, submodules are terrible and are always breaking in inscrutable ways. I guess that that leaves directly copying the functions that are used?