<div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif" class="gmail_default">Oleg (a cabal hero, btw, thank you Oleg) writes</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_default gmail_quote">
 `cabal-install` (and `stack` FWIW) don't want you to have any (implicit) state. That's not great for "real world projects". <br></blockquote><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">But you necessarily have global state anyway!  When I say `ghc -c Foo.hs` I get a particular Prelude, which in turn depends on a bunch of libraries.  My mental model was simply that I can extend that global state, so that rather than only getting Prelude I get whatever libraries I install.  Of course, if I go via cabal, all that global state would be ignored, because cabal would specify everything explicitly.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">To put it another way, I can't figure out why</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><div style="margin-left:40px">
<span>   ghc -c Foo.hs -package this -package that</span><br></div><div style="margin-left:40px"><span></span></div><span>  is any different from<br></span><div style="margin-left:40px"><span>
  cabal build</span><br></div><div style="margin-left:40px"><span></span></div><span>
with a cabal file that has build-depends: this, that.   Except that the former is a lot more convenient for quick compilations.</span></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><span><br></span></div><div style="font-family:tahoma,sans-serif" class="gmail_default"></div><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My impression these past few years is that it's desirable to have one or
 more simple global states, accessible from e.g. ghci, and it's also 
desirable to avoid package conflicts, and there's tension between these 
needs. The above sentiment, though, seems to imply the former simply 
isn't desirable to cabal devs in the first place.<span><br></span></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Oleg mentioned 
<a href="https://github.com/haskell/cabal/issues/6481" rel="noreferrer" target="_blank">https://github.com/haskell/cabal/issues/6481</a>, and Julian drew my attention to 
<a href="https://github.com/haskell/cabal/issues/10098" target="_blank">https://github.com/haskell/cabal/issues/10098</a>.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I am not qualified to have a well-informed opinion about any of this. I'm just reporting one user's surprising (and disappointing) experience.   I'm an outlier in some ways, yes, but here all I wanted to do (as a random GHC user) was compile Foo.hs with a package available, and was surprised that apparently this is no longer possible without creating an auxiliary cabal file and invoking ghc via cabal.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I wonder if there is an articulate writeup of Cabal's mental model.  e.g.  What is an environment file?  Why can't my GHC find Prelude?  If you invoke plain ghc, what packages does it "see"?  Etc.  The user manual is good once you have the basic framework in your head, but it's that "big picture" that I'm missing.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Thanks</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Jul 2024 at 20:06, amindfv--- via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 09, 2024 at 08:50:18PM +0300, Oleg Grenrus wrote:<br>
> cabal-install has various means to address that too. You can have `packages:<br>
> /anywhere/onyourdisk` or `packages: <a href="http://somewhere.else/tar.gz" rel="noreferrer" target="_blank">http://somewhere.else/tar.gz</a> in your<br>
> cabal.project. Or you can have `source-repository-packages` for accessing<br>
> remote git repositories. Or you can setup <a href="https://cabal.readthedocs.io/en/stable/config.html#local-no-index-repositories" rel="noreferrer" target="_blank">https://cabal.readthedocs.io/en/stable/config.html#local-no-index-repositories</a><br>
> for a bit more permanent and reusable solution.<br>
> <br>
> cabal-install has ways to approach those problems *without having a<br>
> stateful/implicit setup*. And the workflow is the same as usual workflow<br>
> with packages and projects. In fact, real work projects do use<br>
> source-repository-packages (and sometimes in project vendored `.tar.gz`<br>
> source distributions).<br>
<br>
Yep, I'm aware (and in fact have used `source-repository-package` on business-critical work projects. I appreciate its existence!).<br>
<br>
However, I'm specifically trying to get to the bottom of the sentiment that "the GHC developers (e.g. you, richard, sebastian) are virtually the only group of people who want to invoke GHC manually."<br>
<br>
My impression these past few years is that it's desirable to have one or more simple global states, accessible from e.g. ghci, and it's also desirable to avoid package conflicts, and there's tension between these needs. The above sentiment, though, seems to imply the former simply isn't desirable to cabal devs in the first place.<br>
<br>
> An anecdote from my side: I wrote`cabal-env` [1] for myself somewhat five<br>
> years ago. I don't think I have used in the last two years. The package<br>
> workflow is often better.<br>
<br>
I've used it! My current work is another attempt to tackle a similar use-case. I disagree (strongly) that for my needs the package workflow is better.<br>
<br>
Cheers,<br>
Tom<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>