search

haskell / docker-haskell

MIT License
63 stars 37 forks source link

Alpine linux version? #22

Open joelmccracken opened 4 years ago

joelmccracken commented 4 years ago

I have been working on an image that uses Alpine, and I was wondering if i submitted a PR, it would be welcome. Of course I will change it however it needs to meet standards, I just want to know before I do the work to make it.

psftw commented 4 years ago

Honestly, you would have a big uphill battle to convince me it is worth doing. Unless a musl-based GHC is in the works and makes it into tier2 status (per https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms ), I don't think supporting Alpine is going to happen.

joelmccracken commented 4 years ago

I see. Well, since I wrote this, I made the one we need, so I'll just put the dockerfile we ended up using here and close the issue:

FROM alpine:3.12

ARG STACK_ALPINE_VERSION=2.3.1

RUN apk add --no-cache \
        alpine-sdk \
        ca-certificates \
        ghc \
        zlib-dev \
        bash

RUN curl -sSfL https://github.com/commercialhaskell/stack/releases/download/v${STACK_ALPINE_VERSION}/stack-${STACK_ALPINE_VERSION}-linux-x86_64-static.tar.gz \
    | tar --wildcards -C /usr/local/bin --strip-components=1 -xzvf - '*/stack' && chmod 755 /usr/local/bin/stack && \
    stack config set system-ghc --global true

Thanks!

utdemir commented 3 years ago

I think there has been some developments in this regard, so I would like to ask for re-opening the issue.

I've been maintaining utdemir/ghc-musl for a while. It used to be finnicky to get a GHC with Alpine when the project was using Nix. However, since I have migrated it to use ghcup, it has been pretty smooth sailing.

My project has a few differences:

Among those differences:

If you are happy with it, I would be keen to help adding ghcup-powered Alpine/musl images to this repository.

AlistairB commented 3 years ago

(Er I wrote a comment then realised it was wrong.. Looks like ghcup is using the official bindists for alpine.)

:wave: Happy to reopen.

Do you know how well supported the alpine ghc release is? I note that there are official bindists for it. My inclination would be to support it if it has no major caveats compared to debian. ie. I think if users get it from the official images they will expect it to just work :tm:

In terms of a solution. https://github.com/haskell/docker-haskell/pull/46#issuecomment-919080565 is one such example. Although, we considered using ghcup in #45 but ultimately chose direct installation. I wonder if ghcup is doing more heavy lifting on alpine? My initial inclination would be to remain consistent and install ghc directly again.

utdemir commented 3 years ago

Do you know how well supported the alpine ghc release is?

So, I've been using ghc-musl for a while, and it seems to work. I'm not developing on it, so I do not know how well the tooling works, but simply running cabal build inside provides a working executable.

There are some rough edges, as some libraries does not like static linking (https://github.com/utdemir/ghc-musl/issues/14, https://github.com/utdemir/ghc-musl/issues/15). But these issues are not specific to GHC, and more about the platform.

I wonder if ghcup is doing more heavy lifting on alpine? My initial inclination would be to remain consistent and install ghc directly again.

I do not know, off the top of my head I do not think ghcup is doing anything special on Alpine than picking up the correct bindist. I used ghcup because only because it was easier. I think you've summarized pros and cons quite well on #45, so I do not have much to add :).

I agree that consistency is important, so I also do not think it's worth introducing ghcup just for Alpine if there is no major advantage. Although, simply because I had such a nice experience with ghcup, I think maintaining this project would become a bit easier if it was using ghcup; but that's just my personal opinion.

AlistairB commented 3 years ago

I love ghcup too :) We might get there, but for now have not seen a clear benefit. Will probably revisit when considering windows support.

Anyway, you are welcome to create a PR with what you are thinking if that works.

AlistairB commented 2 years ago

I'm going to tackle this next.

benz0li commented 2 years ago

See https://gitlab.b-data.ch/ghc/ghc-musl/container_registry for multi-arch (linux/amd64, linux/arm64/v8) GHC docker images based on Alpine Linux; stack not included.

Using https://gitlab.alpinelinux.org/odidev/ghc-bootstrap-aarch64 (GHC 8.8.3) as bootstrap, I have been able to continuously update to the latest version of GHC (currently 9.2.1).

AlistairB commented 2 years ago

Thanks for the info @benz0li ! This will definitely prove useful to better understand the required alpine dependencies.

Although, I think the goal for the official images should be to house the official releases in Docker with minimal modification. Those images look to be more custom builds from source.

One downside of using the official releases is that they target 3.12 and at least 9.2.1 will not work in 3.14. I think I'd like to better understand the long term plan for supporting alpine from the GHC developers and when we can expect newer alpine versions to be supported.

Anyway, for now I need to explore more using the official releases but I guess at this stage all we can do is only support alpine 3.12 and I'm not sure how useful that would be.

AlistairB commented 2 years ago

Ah hmm, looks like https://gitlab.haskell.org/ghc/ghc/-/issues/20266 is the 9.2.1 issue. Perhaps with this resolved it may just work on newer alpine releases. The convention of other official images seems to be to support the last to stable alpine releases which is currently 3.14 + 3.15. This should be the goal for these images as well I think.

benz0li commented 2 years ago

[...] Those images look to be more custom builds from source.

One downside of using the official releases is that they target 3.12 and at least 9.2.1 will not work in 3.14. [...]

As there are no official releases for alpine aarch64 (linux/arm64/v8), those must be custom built from source.

:information_source: The custom built registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4 is used to build the amd64 and arm64 binary releases of pandoc.

benz0li commented 2 years ago

Ah hmm, looks like https://gitlab.haskell.org/ghc/ghc/-/issues/20266 is the 9.2.1 issue. Perhaps with this resolved it may just work on newer alpine releases. [...]

IMHO the source distribution of GHC 9.2.1 is broken. There are some fundamental issues to be resolved for the next release.

GHC 9.0.x builds fine on alpine 3.15 and could be used to build pandoc. GHC 9.2.1 does build, too, but fails to build pandoc.

AlistairB commented 2 years ago

I have something that works ok in https://github.com/haskell/docker-haskell/pull/60 for 9.0. My inclination is to:

benz0li commented 1 year ago

@AlistairB FYI https://gitlab.haskell.org/ghc/ghc/-/issues/23482

benz0li commented 1 year ago

As of 2023‑08‑12, my GHC musl images (versions 9.2.8, 9.4.6, 9.6.2 and later) also include the Haskell Tool Stack (Stack).

ℹ️ See https://github.com/benz0li/ghc-musl for further information.

benz0li commented 1 year ago

The GHC musl repository also provides general purpose Dev Containers:

dev-containers

ℹ️ See GHC musl: Dev Containers for further information.

Cross reference: https://github.com/benz0li/ghc-musl/issues/5#issuecomment-1743079160