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

Evaluate Stack for Haskell Builds #2204

Open
e1528532 opened this Issue Aug 23, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@e1528532
Contributor

e1528532 commented Aug 23, 2018

Since the builds with cabal seem very unstable, evaluate whether using stack makes sense.
Stack seems to be much more focussed on stability, reproducability and long-term support: https://docs.haskellstack.org/en/stable/GUIDE/
As far as i understood it completely sandboxes ghc / cabal / alex and everything instead of using system packages, locked to a fixed set of packages to avoid regressions, i think it makes sense because we just have too many issues otherwise. It would also help with issues where e.g. xenial provides too old ghc packages.

@e1528532 e1528532 self-assigned this Aug 23, 2018

@markus2330

This comment has been minimized.

Show comment
Hide comment
@markus2330

markus2330 Aug 23, 2018

Contributor

Thank you for looking into it!

Having a completely separate ghc/cabal/alex, however, also has disadvantage and distributions like Debian would never package Elektra this way. So we should still support to use the system ghc/cabal/alex.

If stack resolves the problem @Piankero has (it most likely does) it is a great additional option for distributions that do not maintain ghc/cabal/alex.

Contributor

markus2330 commented Aug 23, 2018

Thank you for looking into it!

Having a completely separate ghc/cabal/alex, however, also has disadvantage and distributions like Debian would never package Elektra this way. So we should still support to use the system ghc/cabal/alex.

If stack resolves the problem @Piankero has (it most likely does) it is a great additional option for distributions that do not maintain ghc/cabal/alex.

@e1528532

This comment has been minimized.

Show comment
Hide comment
@e1528532

e1528532 Aug 23, 2018

Contributor

Having a completely separate ghc/cabal/alex, however, also has disadvantage and distributions like Debian would never package Elektra this way.

Stack supports using the system ghc as well with the --system-ghc command line parameter. Furthermore it does not replace cabal, it is more like an additional layer above cabal to get rid of the built and stability issues we've encountered. I'd check if i can support both ways somehow but first i evaluate whether it works with cmake at all.

Building debian packages with stack doesn't seem impossible though: https://www.reddit.com/r/haskell/comments/7tgnwc/how_to_make_a_debian_package_out_of_a_haskell/

Contributor

e1528532 commented Aug 23, 2018

Having a completely separate ghc/cabal/alex, however, also has disadvantage and distributions like Debian would never package Elektra this way.

Stack supports using the system ghc as well with the --system-ghc command line parameter. Furthermore it does not replace cabal, it is more like an additional layer above cabal to get rid of the built and stability issues we've encountered. I'd check if i can support both ways somehow but first i evaluate whether it works with cmake at all.

Building debian packages with stack doesn't seem impossible though: https://www.reddit.com/r/haskell/comments/7tgnwc/how_to_make_a_debian_package_out_of_a_haskell/

@markus2330

This comment has been minimized.

Show comment
Hide comment
@markus2330

markus2330 Aug 23, 2018

Contributor

If stack supports the system ghc and still works without problems it sounds like a very good thing. I also had troubles running your plugin but I would not go as far as installing a new ghc.

Building debian packages with stack doesn't seem impossible though

not impossible != acceptable effort

The haskell parts are not in the Debian package anyway but we might make it more difficult if someone tries. But I cannot really tell, I do not have any experience in packaging Haskell programs. I only mentioned it so that you are aware. Making the developers lives easier (automatic downloading of random packages from the Internet) often implies making the package maintainers life a lot harder.

Contributor

markus2330 commented Aug 23, 2018

If stack supports the system ghc and still works without problems it sounds like a very good thing. I also had troubles running your plugin but I would not go as far as installing a new ghc.

Building debian packages with stack doesn't seem impossible though

not impossible != acceptable effort

The haskell parts are not in the Debian package anyway but we might make it more difficult if someone tries. But I cannot really tell, I do not have any experience in packaging Haskell programs. I only mentioned it so that you are aware. Making the developers lives easier (automatic downloading of random packages from the Internet) often implies making the package maintainers life a lot harder.

@e1528532

This comment has been minimized.

Show comment
Hide comment
@e1528532

e1528532 Aug 23, 2018

Contributor

Current insights from trying stack:

In general stack uses some kind of snapshot of ghc packages to provide a stable environment. This also defines ghc versions and such things.
https://github.com/commercialhaskell/lts-haskell
In case i try the lts resolver for ghc 8.0.1 (as delivered on debian stretch) it contains a lot of packages in old versions that are incompatible with the current code. They might be only 2 years old but haskell as a whole is a rather fast-evolving environment with little care about backwards compatibility.
I can do adjustments but i think overall this all just adds unnecessary maintenance work.

Ultimately i think the easiest thing would be just requiring e.g. 8.2.2 and let stack handle everything and the appropriate snapshot set of packages and building everything with that + statically linking the haskell runtime or providing the appropriate libraries with elektra.

I am sure you won't like this as you care more about linux packages than i do but to me it seems the easiest way to get a stable environment, otherwise there will be always some combination of libraries and/or ghc versions causing problems. Also in general the compilation/build procedure with stack seems more stable than with cabal alone.

Contributor

e1528532 commented Aug 23, 2018

Current insights from trying stack:

In general stack uses some kind of snapshot of ghc packages to provide a stable environment. This also defines ghc versions and such things.
https://github.com/commercialhaskell/lts-haskell
In case i try the lts resolver for ghc 8.0.1 (as delivered on debian stretch) it contains a lot of packages in old versions that are incompatible with the current code. They might be only 2 years old but haskell as a whole is a rather fast-evolving environment with little care about backwards compatibility.
I can do adjustments but i think overall this all just adds unnecessary maintenance work.

Ultimately i think the easiest thing would be just requiring e.g. 8.2.2 and let stack handle everything and the appropriate snapshot set of packages and building everything with that + statically linking the haskell runtime or providing the appropriate libraries with elektra.

I am sure you won't like this as you care more about linux packages than i do but to me it seems the easiest way to get a stable environment, otherwise there will be always some combination of libraries and/or ghc versions causing problems. Also in general the compilation/build procedure with stack seems more stable than with cabal alone.

@e1528532

This comment has been minimized.

Show comment
Hide comment
@e1528532

e1528532 Aug 23, 2018

Contributor

I think i've managed to make it compatible with lts-7.24 now as debian stretch was the "lower bound" for haskell before.
Still in case one uses e.g. xenial we need to link the appropriate haskell runtimes or ship them with elektra anyway cause we can't use the system ones. So i think there is no real way around that.

Contributor

e1528532 commented Aug 23, 2018

I think i've managed to make it compatible with lts-7.24 now as debian stretch was the "lower bound" for haskell before.
Still in case one uses e.g. xenial we need to link the appropriate haskell runtimes or ship them with elektra anyway cause we can't use the system ones. So i think there is no real way around that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment