The new nix-style Cabal is a fat monster
krangelov opened this issue · 10 comments
I upgraded my GHC version and with that I also got the new Cabal which uses v2 commands by default. It promises to solve the Cabal hell but in my opinion it makes everything even more complicated. Every time when you compile a package it gets an unique hash code which is then baked in in every exported symbol from every executable or library.
Furthermore after every recompilation the produced binary is put in another folder. For instance you can find the gf binary in a folder like this:
~/.cabal/store/ghc-8.8.4/gf-3.11.0-46d45029734611904857f06749335e382c378b1bc656ff7fd6eab8198d9c3297/bin/gf
where the long sequence of numbers is the hash code. The code changes every time when you change something in the GF code!
The consequence is that this also affects how GF finds the RGL library and the root folder for the web server. The two are now:
~/.cabal/store/ghc-8.8.4/gf-3.11.0-46d45029734611904857f06749335e382c378b1bc656ff7fd6eab8198d9c3297/share/lib
~/.cabal/store/ghc-8.8.4/gf-3.11.0-46d45029734611904857f06749335e382c378b1bc656ff7fd6eab8198d9c3297/share/www
Of course this means that, if you change something in the GF compiler, then you also must recompile the RGL.
The GF setup script used to compile and install some example grammars in the web folder. This doesn't work anymore either.
My suggestion is to change the location for the RGL and the web root to:
~/.gf/lib
~/.gf/www
Also the code for the GF Cloud will be moved to a new repository gf-cloud, which will install to ~/.gf/www. The GF setup cannot do the installation anymore.
Let me know your opinion before I start moving things!
Also, let me know if you have the same issue with Stack.
There is a similar issue with Slack, for example my webroot directory is:
/Users/john/repositories/GF/gf-core/.stack-work/install/x86_64-osx/0e9b623a2c23e56fbdb5b7f2d400161e4d74f67ec840f528e0870958fff3066c/8.2.2/share/x86_64-osx-ghc-8.2.2/gf-3.10/www
Although I don't think this changes whenever the source code changes, but based on the Stack build settings and of course GHC version.
Either way, I'm all for moving the RGL and web files into a the user home directory as you suggest.
I don't really have an opinion about that, sounds fine to me.
After a lot of trial and error, I came to the conclusion that the best solution is to simply stop using cabal-install for development. Note that the Cabal library is still sane, it is just the cabal-install tool that is wicked. It still works if you are happy to reinstall the RGL and the WordNet after every change in the compiler but this is hardly satisfactory.
What I did instead is to update Setup.hs to also install the GF dependencies. Fortunately I have always strived to keep the dependencies to a minimum. They can be reduced even further but I am not going to do this yet. If you want to avoid cabal-install, simply do:
runghc Setup.hs configure
runghc Setup.hs build
sudo runghc Setup.hs install
This has the added advantage that now gf goes to "/usr/local/bin" as it used to do in the good old days. Another change is that gf --version now also prints where GF expects to find the RGL lib folder. I will use that in the Setup script for the RGL.
I understand how that is frustrating while developing GF. It's good that you found a workaround and documented it.
But installing the package dependencies globally has obviously other potential problems, namely unresolvable dependency conflicts between projects which are best solved by nuking the installed packages and starting over. 😒
So I have a little sympathy for the new way of doing things, but yes it comes at a cost too...
What about the effort to move gf-cloud into a separate repo, will you abandon that?
[..] namely unresolvable dependency conflicts between projects which are best solved by nuking the installed packages and starting over.
ArchLinux is packaging hundreds of packages build by Setup configure // build (example), so I'd say that it is still a viable way.
cabal-install-3.0 does use the nix-style commands by default, but it is still possible to use the old version, by prefixing the commands with old- or v1-. So instead of running cabal build you run cabal v1-build and everything should work as usual. No need for the madness in 1294269 to work around it.
I don't think the data-dirs generated by cabal was ever intended to be mutated after the fact and used as a general data-store like gf does. It was intended as a place to put extra files from the tarball and nothing else. The only reason we have this problem is that those directories has been abused as general configuration directories.
The real solution would be to have a sane default for GF_LIB_PATH and similar directories like you suggested and stop assuming that whatever directory happens to be in Paths_gf is a good one.
The current strategy only works specifically with old-style cabal, not with new-style cabal, not with stack and not at all with nix (not to be confused with cabal's nix-style-builds) since it puts the generated directories read-only file system. Every other case requires manually configuring GF_LIB_PATH (and the root of the web server) to not go insane.
@krangelov Is there any other pain you've experienced with using cabal-install that makes it not worth it? Because as I've said, the old functionality is still there, you just need to prefix the commands with v1-.
I have had some problems when trying to build the latest master because of the changes in 1294269, but I admittedly have a pretty niche setup using nix as the build/package management system instead of stack or cabal.