The new nix-style Cabal is a fat monster

[krangelov]

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!

[krangelov]

Also, let me know if you have the same issue with Stack.

[johnjcamilleri]

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.

[krangelov]

Ok. Nice that we have an agreement. One more issue that I thought about after the last post. For development using ~/.gf would be fine, but I think when we prepare binary releases then we should put the binary in /usr/bin/gf and then all the data files in /usr/share. Something equivalent on Windows of course.

…

On Mon, 22 Aug 2022 at 08:10, John J. Camilleri ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZE44LN3OTAAYXTF2CLV2MKUNANCNFSM57BT6F6A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[johnjcamilleri]

I don't really have an opinion about that, sounds fine to me.

[krangelov]

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.

[johnjcamilleri]

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?

[kiufta]

[..] 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.

[anka-213]

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]

It is still possible to use cabal & stack for those who want it. For me it is not worth the pain. I have always installed all packages globally. It works great as long as you stick with simple and stable packages. Just because a package offers a fancy new monad or gonad doesn't mean that it is worth it. Just as an example - using the JSON package doesn't bring any other dependencies apart from those that come together with GHC. On the other hand using Aeson brings in plenty of other packages which are completely unnecessary if you just want to parse a simple text format. This makes Aeson a lot more susceptible to breaks. For GF, I have always prioritized simplicity. As much as I love Haskell, I more and more envy Python where the infrastructure is more stable and better organized. Splitting gf-cloud is not necessary now. Moreover, even if I move the web stuff there will still be bits of Haskell code in the compiler which are needed to keep the cloud functional. Splitting those is not impossible but it will make everything harder to set up and install. I will leave things as they are.

…

On Thu, 25 Aug 2022 at 20:09, John J. Camilleri ***@***.***> wrote: 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? — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZH6GIN5B2L7KAV5ME3V26ZEHANCNFSM57BT6F6A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[anka-213]

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