The new nix-style Cabal is a fat monster #146
Comments
|
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: 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. |
|
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:
***@***.***>
|
|
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 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 |
|
I understand how that is frustrating while developing GF. It's good that you found a workaround and documented it. What about the effort to move gf-cloud into a separate repo, will you abandon that? |
ArchLinux is packaging hundreds of packages build by |
|
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 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 |
|
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:
***@***.***>
|
|
@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 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. |
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:
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:
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:
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!
The text was updated successfully, but these errors were encountered: