delete `.stack-work` was not a good idea
Closed this issue · 13 comments
Now, trying to build a package that depends on ihaskell will cause a rebuild of ihaskell, which will fail because the user does not have group write permission in /opt/IHaskell/.stack-work.
So we should fix those permissions, and also not clean /opt/IHaskell/.stack-work.
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨
It seems unfortunate that the Docker image has to keep around .stack-work (7GB, the Dockerfile says) just in case the user wants to build a package that depends on ihaskell.
This Docker image looks promising, but the 9.44 GB size is less than ideal. What is the workflow that raised this issue? If I'm building a package depending on ihaskell, shouldn't it try to build ihaskell from Hackage like it would any other stack dependency?
Yeah, the image is massive, and that's a problem.
What is the workflow that raised this issue?
I think I was building the https://github.com/gibiansky/IHaskell/tree/master/ihaskell-display packages on the fly in the container.
If I'm building a package depending on
ihaskell, shouldn't it try to buildihaskellfrom Hackage like it would any other stack dependency?
Yeah, I like that idea.
These days, all of those ihaskell-display packages are prebuilt in the image. The theme of this image is “all batteries included.”
The thing is, IHaskell is fundamentally a Haskell runtime build environment. Every time I've tried to clean out some of the build dependencies in the image, I've found that it cripples some part of the IHaskell runtime build environment. But maybe we could figure out a way to get a smaller usable image. I would like that. We have to make sure we preserve the ability to install new packages in notebooks.
Also I'm following your work in IHaskell/IHaskell#1252 and I like what you're trying do.
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨
Yeah, there's definitely some give-and-takes in this work. Maybe have two separate images, one with a "minimal JupyterLab installation with IHaskell kernel support" and one with "all batteries included with ihaskell-display at the cost of a bigger image"?
What does ihaskell-display do? I'm still unsure what that does.
We have to make sure we preserve the ability to install new packages in notebooks.
Definitely. I think since I got rid of the dynamic linking in the ihaskell executable, we should need less of a build-environment-at-runtime. But there will need to be some minimal build environment (e.g. stack installed on the Docker image) so that users can still install hackage packages.
Definitely. I think since I got rid of the dynamic linking in the ihaskell executable, we should need less of a build-environment-at-runtime.
Yeah sweet, I'm excited about that possibility.
What does ihaskell-display do?
It's the family of optional packages which provide all of the fancy notebook output, like HTML and LaTeX and images. For example: https://mybinder.org/v2/gh/jamesdbrock/learn-you-a-haskell-notebook/master?urlpath=lab/tree/ihaskell_examples/WidgetRevival.ipynb
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨
I see, very cool! But if I basically just want a glorified GHCi, I would probably never use those. What do you think about having the two Docker images?
What do you think about having the two Docker images?
Yes, great. More Docker images would be better.
Also I want to make sure you know about this project? https://github.com/tweag/jupyterWith
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨
Cool! I personally am not a fan of Nix and don't have it installed, but if you do have it installed, it looks like a handy solution
Cool! I personally am not a fan of Nix and don't have it installed, but if you do have it installed, it looks like a handy solution
In that case, I recommend you try to get jupyterWith working. I think you would really like it, and it may be what you're looking for.
I'm looking at the jupyterWith installation instructions right now, and unfortunately it contains some wrong information, written by me, about how to get synax highlighting working.
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨
To be clear, I'm not willing to install Nix just to get jupyterWith working
You would love Nix!
It's super easy to install the Nix package manager (not the NixOS) and if you don't use it then it barely takes up any space on your system.
✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨
My company moved off of Nix because it took up so much space. I had to delete ~/.nix often because it took up so much space. Plus there were linking issues since Mac OS limits the length of paths when loading dylibs. I'm sure those problems are better now, but I don't have the time to experiment with it again now. Sorry 🤷