Create release plan/script
Releases became more complicated since the addition of atom function scripting. The release should likely be a zip file which includes the precompiled binaries alongside a lib directory containing the requisite haskell library dependencies.
Is this referring to a way to do migrations?
This issue turns out to affect all platforms and we don't yet have an obviously best solution yet. User feedback would be appreciated. The ideal goal is to create a binary distribution in a zip-file which the user can download and run right away.
Specifically, the issue is that cabal packages are not relocatable and cabal support for relocatable packages is limited, so bundling them into a directory structure alongside the binaries may be difficult. The Haskell packages are loaded in order to compile atom function bodies at runtime, which is a great feature.
If the goal is to produce a platform-specific zip file with all the requisite libraries and binaries, then the options appear to be:
- use cabal to determine which dependencies are needed for the various packages Project:M36 will need at runtime, use a variety of tools to munge cabal-built packages so that they are relocatable (though it is unclear if this will work in practice)
- create a pre-built set of packages to bundle with Project:M36 (tracking the GHC version of the release)
- require users who want to use the feature to build Project:M36 for themselves (probably the worst option)
Clearly, none of these options are particularly appealing. Is there a better way?
Which of these is the easiest? It seems (3) would be simplest, albeit not the most convenient. But having a solution is better than no solution and you can always improve after that.
Right now, the feature dependencies are punted to the users. The various binaries include a --ghc-pkg-dir option (which can be specified multiple times) to point to package directories with the dependencies. But using this option presupposes a lot of GHC knowledge, such as matching GHC version and just knowing what the dependencies might be (which is not yet documented but can be found here.
One immediate improvement is to simply disable the scripting feature if the GHC libraries are not available- currently, the binaries spit out some warning. I will implement that.
The executables can now run with atom function scripting disabled if the GHC dependencies are missing.