Would you be so kind as to include stack? about ghc-musl

[TravisCardwell]

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.

[TravisCardwell]

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]

@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]

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]

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]

@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.