Hi, Am Donnerstag, den 18.02.2021, 19:52 +0000 schrieb Richard Eisenberg:

As someone who usually works on individual scraps of Haskell (not projects), I frequently wish to do the same and have struggled with both cabal and stack in getting what I want.

Happily, there is a nicely working alternative to both: cabal-env from https://github.com/phadej/cabal-extras works great. I use it regularly. It does what you want.

I couldn't find a README, hard to see what it does exactly. Is it just more convenience around the idiom of using cabal install --env . --lib ghc-heap-view to get a .ghc.environment file in the local directory (which is, as long as you use ghc or ghci in that directory, as good as the good old cabal v1-install, it seems)? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

On Feb 18, 2021, at 3:48 PM, Viktor Dukhovni wrote:

$ cabal repl -v0 -z --repl-options -package=iproute --repl-options -XOverloadedStrings

Yes, but it's so, so much easier just to say `ghci`. And then I can pass lots of options to `ghci` directly when I want to. And I don't have to spend time writing and maintaining wrapper scripts. I do know what can go wrong with a global package database, and sometimes (once every 2-3 years?) it does go wrong. But I still prefer to work with a global database for my usual workflow. Richard

I agree - and had a run-around with this same issue recently (https://stackoverflow.com/questions/65836038/haskell-timeit-module-systemtim...) The options for simple usage were failing - a JIRA was filed: "ghc and ghci don't read the default package environment file on Windows" https://gitlab.haskell.org/ghc/ghc/-/issues/19286 -----Original Message----- From: Haskell-Cafe On Behalf Of MigMit Sent: Thursday, February 18, 2021 3:37 PM So do I. But it seems to me like a global trend: more and more tools are designed to make our life easier, and it becomes harder and harder to deal with the mess they create.

On 18 Feb 2021, at 22:15, Richard Eisenberg wrote:

Yes, but it's so, so much easier just to say `ghci`. And then I can pass lots of options to `ghci` directly when I want to. And I don't have to spend time writing and maintaining wrapper scripts.

On Thu, Feb 18, 2021 at 09:15:53PM +0000, Richard Eisenberg wrote:

...

On Feb 18, 2021, at 3:48 PM, Viktor Dukhovni wrote:

$ cabal repl -v0 -z --repl-options -package=iproute --repl-options -XOverloadedStrings

Yes, but it's so, so much easier just to say `ghci`. And then I can pass lots of options to `ghci` directly when I want to. And I don't have to spend time writing and maintaining wrapper scripts.

I was reminded of this thread because I just saw yet another post (this time on Haskell Discourse) from a user confused about how the v1-style global package database is supposed to work these days. In this thread we had a few people mention that they prefer the "global package database" style. I'd like to improve my understanding of why people prefer that style. I believe it was only Richard who explained his rationale (above). For me personally, "global package database" style was useful because I could "cabal install" a package and then "ghc" or "ghci" would have it immediately available. However, I have since given up trying to get that style to work and now I use the "--build-depends" or "create a temporary cabal package" approach[0]. So what are the benefits of the "global package database" workflow style? Is it just that cabal -z repl --package QuickCheck --repl-options="whatever" is more of a pain to type than ghci "whatever" and that creating a .cabal file and running "cabal build" is more of a pain than typing "ghc", or is there something fundamental that the "global package database" supports that cabal v2-style does not? Tom [0] http://h2.jaguarpaw.co.uk/posts/how-i-use-cabal/

...

cabal -z repl --package QuickCheck --repl-options="whatever"

is more of a pain to type than

ghci "whatever"

and that creating a .cabal file and running "cabal build" is more of a pain than typing "ghc", or is there something fundamental that the "global package database" supports that cabal v2-style does not?

Maybe it's superficial, but this is the big thing for me, yes. I also tend to have long-running ghci sessions, and so I don't always know what packages I'll want before launching.

Some of this is also, for me, philosophical: I don't want anything between me and GHC. That is, I want to know exactly what flags are being passed to GHC and to be able to control those flags myself. A tool that installs libraries should do that, and then get out of the way.

I think this amounts to a call for action to fix `cabal install --lib` (assuming the v2- variant). Indeed when I tried this with cabal-head my cabal store became unusable, which hasn't happened to me for a very long time now. (Deleting ~/.cabal/store/ghc-8.2.2 fixed it.) Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

On Sun, Mar 21, 2021 at 08:14:09AM +0000, Tom Ellis wrote:

On Thu, Feb 18, 2021 at 03:35:10PM -0500, Viktor Dukhovni wrote:

...

You can use "cabal repl -z" to run ghci with the Cabal "user" package database in scope:

I'm confused by this. What is 'the Cabal "user" package database'? The --help text says

-z --ignore-project Only include explicitlyspecified packages (and 'base').

With the "-z" flag, "cabal repl" stops looking for ".cabal" files in the current directory (sandbox if you like), and just works with whatever is installed in the Cabal package database. Thus, because I've previously compiled optparse-applicative and streaming-bytestring: $ (cd ~/.cabal/store/ghc-8.10.4; ls -d optparse-applicative* streaming-byte*) optparse-applicative-0.16.1.0-eee378057b7539bcf75579d76e9f4ff170b047a9ccc498b6fe1ba5d2dfa9075a streaming-bytestring-0.2.0-8e7f82f7151e104bdca4aac21a045ebe5b332e0490a839f8fba8a3901dfcd58a I can run: $ cabal repl -v0 -z λ> import Data.Either λ> :set -package bytestring λ> import Data.ByteString λ> :set -package streaming-bytestring λ> import Streaming.ByteString λ> :set -package optparse-applicative λ> import Options.Applicative λ> :t strOption strOption :: Data.String.IsString s => Mod OptionFields s -> Parser s λ> :t unconsChunk unconsChunk :: Monad m => ByteStream m r -> m (Either r (Data.ByteString.ByteString, ByteStream m r)) whereas the same does not generally work with just ghci, which does not know about Cabal's package store: $ ghci -v0 λ> :set -package bytestring λ> :set -package streaming-bytestring cannot satisfy -package streaming-bytestring (use -v for more information) λ> :set -package optparse-applicative cannot satisfy -package optparse-applicative (use -v for more information) However, (perhaps dependent on one's Cabal configuration settings) when I use "cabal install --lib some-package" I also end up with a GHC environment file created as a side-effect of the "cabal install". Below I request "base" which is already there, so the only effect is to create the environment file: $ cabal install --lib base Resolving dependencies... Up to date $ cat ~/.ghc/x86_64-freebsd-8.10.4/environments/default clear-package-db global-package-db package-db /home/viktor/.cabal/store/ghc-8.10.4/package.db package-id ghc-8.10.4 package-id bytestring-0.10.12.0 package-id unix-2.7.2.2 package-id base-4.14.1.0 package-id time-1.9.3 package-id hpc-0.6.1.0 package-id filepath-1.4.2.1 package-id process-1.6.9.0 package-id array-0.5.4.0 package-id integer-gmp-1.0.3.0 package-id containers-0.6.4.1 package-id ghc-boot-8.10.4 package-id binary-0.8.8.0 package-id ghc-prim-0.6.1 package-id ghci-8.10.4 package-id rts-1.0.1 package-id terminfo-0.4.1.4 package-id transformers-0.5.6.2 package-id deepseq-1.4.4.0 package-id ghc-boot-th-8.10.4 package-id pretty-1.1.3.6 package-id template-haskell-2.16.0.0 package-id directory-1.3.6.0 package-id text-1.2.4.1 Once the environment file is in place, I can: $ ghci -v0 λ> import Data.Either λ> :set -package optparse-applicative λ> import Options.Applicative λ> :set -package streaming-bytestring λ> import Streaming.ByteString λ> :set -package bytestring λ> import Data.ByteString λ> :t strOption strOption :: Data.String.IsString s => Mod OptionFields s -> Parser s λ> :t unconsChunk unconsChunk :: Monad m => ByteStream m r -> m (Either r (Data.ByteString.ByteString, ByteStream m r))

I can't see any evidence locally that it brings any packages into scope. Could you please clarify exactly what -z is doing in your example below?

With "-z" I can load any pre-built library from the Cabal package store, rather than just the dependencies of the current project. -- Viktor.