utdemir/ghc-musl

Would you be so kind as to include stack?

Opened this issue · 6 comments

why-not-try-calmer commented

I was enthusiast when I read that Images come with ghc and cabal executables alongside with commonly used libraries and build tools. Finding out that stack must be manually installed was disappointing. Of course, it's quite simple for the end user to add stack, but I think this does not honor the promise made in the sentence quoted.

Let's not forget all those who enjoy easy builds from Stackage snapshots... :)

edit: I realize there is a Stack workflow that is already supported, i.e using Stack from the host to build the target image. But you base image also allows to produce nice statically linked executables from outside the host, i.e. from a CI/CD runner. It is in particular in this context that it would be appreciable to have Stack pre-installed, so as to be able to use the image you offer as a build context to copy an executable from.

TravisCardwell commented

Indeed, Stack usage is currently supported via Stack's Docker integration, where Stack on a host can use a ghc-musl container to build static executables. I support Stack in my projects, so this is well tested.

Including Stack in the container image should not be a problem. It can be configured to use the GHC that is already installed within the container, so adding it should result in only a ~77MB increase in the image size. I will test this as soon as I get a chance, hopefully soon.

  • ❤️2
TravisCardwell commented

I implemented this in the above-linked commit. Looking at the image sizes (for GHC 9.2.4), it results in ~1.69 GB increase. So much for my ~77MB estimate! 😆 That ~77MB is for the Stack installation, but quite a bit is stored in the .stack directory even without installing (another) GHC.

~/.stack # du -h
878.2M  ./pantry/hackage
1.5G    ./pantry
1.5G    .

@utdemir What do you think? If you would like to include this, I suggest the following steps:

  1. Merge #27
  2. I will rebase my stack branch and create a PR
  3. Merge that new PR
  4. Release
    • update-readme.sh
    • Build/push new images

By the way, I hope to resume/restart my new documentation changes soon, but I doubt I will have time to get to it this weekend.

utdemir commented

@TravisCardwell thank you for working on this and your investigations!

I feel pretty much the same with you, having stack would be useful within the docker containers, however I don't think I'd be willing to add 2 gigabytes to each image.

I wonder if there can be a compromise. What if we were to include stack within the image, but not do a stack update? This way, hopefully we wouldn't have the .stack directory. So if someone were to use stack within the image, they'd need to do a stack update themselves, but at least it'd be simpler than installing stack.

@why-not-try-calmer what do you think? Does having stack in the images, but still having to do a stack update works for you?

@TravisCardwell otherwise, I'm happy with the steps you suggested.

TravisCardwell commented

I have been thinking along the same lines. I can add a flag so that stack update is not run by default, resulting in smaller images on Docker Hub. Users who build their own images can enable stack update using a build argument.

Running stack update in a CI job increases the run time and network usage of the job. Providing a flag will allow people to avoid this cost in cases where it is an issue.

Would you like to do the same with Cabal, by chance?

~/.cabal # du -h
884.9M	./packages/hackage.haskell.org
884.9M	./packages
884.9M	.
TravisCardwell commented

Here is the table from the above commit message, so that GitHub will render it:

cabal update stack update Image Size Relative Image Size
Disabled Disabled 2.83GB 100%
Enabled Disabled 3.76GB 133%
Enabled Enabled 5.37GB 190%
why-not-try-calmer commented

@TravisCardwell thank you for working on this and your investigations!

I feel pretty much the same with you, having stack would be useful within the docker containers, however I don't think I'd be willing to add 2 gigabytes to each image.

I wonder if there can be a compromise. What if we were to include stack within the image, but not do a stack update? This way, hopefully we wouldn't have the .stack directory. So if someone were to use stack within the image, they'd need to do a stack update themselves, but at least it'd be simpler than installing stack.

@why-not-try-calmer what do you think? Does having stack in the images, but still having to do a stack update works for you?

@TravisCardwell otherwise, I'm happy with the steps you suggested.

Hello, thanks for working on this, I think it's very reasonable to expect the end user to run stack upgrade (in fact that's how it's done with most project / dependency managers in most languages nowadays). Also this is exactly how I did it for my personal use case (I committed to your official image an extra ghcup install stack but didn't include update).

So thanks a lot guys, really appreciated! Looking forward to using these brand new images.