Skip to content

Create release plan/script #43

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
agentm opened this issue Aug 31, 2016 · 5 comments
Open

Create release plan/script #43

agentm opened this issue Aug 31, 2016 · 5 comments
Assignees

Comments

@agentm
Copy link
Owner

agentm commented Aug 31, 2016

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.

@agentm agentm self-assigned this Aug 31, 2016
@agentm agentm changed the title Create Windows release plan/script Create release plan/script Sep 12, 2016
@3noch
Copy link
Contributor

3noch commented Sep 12, 2016

Is this referring to a way to do migrations?

@agentm
Copy link
Owner Author

agentm commented Sep 12, 2016

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:

  1. 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)
  2. create a pre-built set of packages to bundle with Project:M36 (tracking the GHC version of the release)
  3. 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?

@3noch
Copy link
Contributor

3noch commented Sep 12, 2016

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.

@agentm
Copy link
Owner Author

agentm commented Sep 13, 2016

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.

agentm added a commit that referenced this issue Sep 13, 2016
@agentm
Copy link
Owner Author

agentm commented Sep 13, 2016

The executables can now run with atom function scripting disabled if the GHC dependencies are missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants