Re: Proposal: Don't read environment files by default

[Simon Marlow]

On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus  wrote:

>
> On 7.4.2019 17.21, Simon Marlow wrote:
> > As I understand it, the aim is to support workflows like "cabal
> > install $pkg; ghci" (amongst other things). This currently works with
> > 'cabal install' because it installs into the global package DB, but it
> > doesn't work with 'cabal new-install' which installs into
> > `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a
> > .ghc-environment file in the current directory, even outside of a
> > cabal package/project? I would find that *very* surprising as a user.
>
> This is not correct.


Well, it was a question :)


> Cabal doesn't write (local) .ghc.environment files
> when you `cabal v2-install` __outside__ the project (actually it
> doesn't, even when you `v2-install` the local project either, as you
> don't build the local project then).
> - When you install an executable, say `cabal v2-install alex` it do
> nothing related to environment files (there is inference in reading them
> atm though)
> - When you install a library, say `cabal v2-install distributive --lib`,
> then `cabal` (tries to) update
> `~/.ghc/-/environments/default` (or specified
> environment), so following
> `ghci` or `(ghci -package-env=somename) could pickup that library.
>

Thanks, I wasn't aware of the default environment file. Seems perfectly
reasonable to me.


> Instead of cabal ghci -package $pkg you can do
>
> cabal v2-install $pkg1 --lib --package-env=foo
> cabal v2-install $pkg2 --lib --package-env=foo
> ...
> ghci -package-env=foo
>
> Or alternatively
>
> cabal v2-repl -b $pkg
>
> Unfortunately neither way is (known) bug free at the moment. I mostly
> use the former, with the `default` package-env (then I can omit
> --package-env flags) for all kind of experiments, e.g. to try out things
> when answering people on `#haskell` or Stack Overflow; but I have my own
> way to create environment file (i.e. I don't use v2-install --lib), as
> cabal is atm not perfect, see Cabal's issue 5888. It's however important
> to note, that `cabal` makes `ghc` ignore these global environments
> (especially the default one) in builds etc, so `cabal v2-build` works.
>

This all sounds good to me. I hope you can work out the bugs!

Cheers
Simon


> I suppose I somewhat agree with those who are calling for environment
> > files to require a command-line flag. We've gone to all this trouble
> > to make a nice stateless model for the package DB, but then we've
> > lobbed a stateful UI on top of it, which seems odd and is clearly
> > surprising a lot of people.
>
> I disagree. I created `~/.ghci` and `~/.../environments/default` because
> I want some defaults. Note: with v1-install people managed
> user-package-db, with v2-install you are supposed to manage
> environment(s). Yet, you can also only use `cabal v2-repl` or `cabal
> v2-run` (See "new-run also supports running script files that ..." in
> https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run
> ).
>
> Most of the above works (sans known bugs), and if you run Ubuntu, I
> invite you to try it out, as it's easy to install from Herbert's PPA:
> https://launchpad.net/~hvr/+archive/ubuntu/ghc
>
> >
> > Cheers
> > Simon
> >
> > On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel
> > mailto:hvrie...@gmail.com>> wrote:
> >
> > Matthew,
> >
> > I realize this to be a controversial issue, but what you're
> suggesting
> > is effectively an attempt at cutting this cabal V2 feature off at
> > the knees
> > ("If Cabal won't change its default let's cripple this feature on
> > GHC's
> > side by rendering it pointless to use in cabal").
> >
> > If ghc environment aren't read anymore by default they fail to have
> > the purpose they were invented for in the first place!
> >
> > At the risk of repeating things I've tried to explain already in the
> > GitHub issue let me motivate (again) why we have these env files: We
> > want to be able to provide a stateful interface providing the common
> > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
> > already provided in the past; e.g.
> >
> >
> > ,
> > | $ cabal v1-install lens lens-aeson
> > |
> > | $ ghc --make MyProgUsingLens.hs
> > | [1 of 1] ...
> > | ...
> > |
> > | $ ghci
> > | GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
> > | Prelude> import Control.Lens
> > | Prelude Control.Lens>
> > `
> >
> > or similarly, when you had just `cabal v1-build` something, you'd get
> > access to your projects dependencies which were installed into ghc's
> > user pkg-db.
> >
> > This is also a workflow which has been well documented for over a
> > decade
> > in Haskell's literature and instructions *and* this is the same
> > idiom as
> > used by many popular package managers out there ("${pkgmgr} install
> > somelibrary")
> >
> 

Re: Proposal: Don't read environment files by default

[Oleg Grenrus]

On 7.4.2019 17.21, Simon Marlow wrote:
> I've also been surprised (not in a good way) by environment files. But
> I haven't followed all the discussion so I still have some questions.
>
> As I understand it, the aim is to support workflows like "cabal
> install $pkg; ghci" (amongst other things). This currently works with
> 'cabal install' because it installs into the global package DB, but it
> doesn't work with 'cabal new-install' which installs into
> `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a
> .ghc-environment file in the current directory, even outside of a
> cabal package/project? I would find that *very* surprising as a user.

This is not correct. Cabal doesn't write (local) .ghc.environment files
when you `cabal v2-install` __outside__ the project (actually it
doesn't, even when you `v2-install` the local project either, as you
don't build the local project then).
- When you install an executable, say `cabal v2-install alex` it do
nothing related to environment files (there is inference in reading them
atm though)
- When you install a library, say `cabal v2-install distributive --lib`,
then `cabal` (tries to) update
`~/.ghc/-/environments/default` (or specified
environment), so following
`ghci` or `(ghci -package-env=somename) could pickup that library.

For playing with libraries, you can manage multiple environments, and
starting over (as you will eventually run into incompatible package
versions) isn't as expensive, as packages are still cached in store.
This is however a goal, and not yet a reality, due to bugs in cabal: see
e.g https://github.com/haskell/cabal/issues/5888 and
https://github.com/haskell/cabal/issues/5559 issues.

>
> Indeed it almost works to say 'ghci -package-db
> ~/.cabal/store/ghc-8.4.3/package.db` after 'cabal new-install $pkg',
> but this might fail if there are conflicts in the package DB
> preventing the use of $pkg. GHC does some not-very-clever constraint
> solving to end up with a consistent set of packages, and you can guide
> it by adding '-package $pkg' flags. But it's still not very clever,
> and might fail.
>
> Instead what if we had something like 'cabal ghci -package $pkg' to
> indicate that you want to start GHCi with $pkg available? It would be
> Cabal's job to ensure that $pkg was built and made available to GHCi.
> For more complex cases, you can create a package or a project, but
> simple ad-hoc invocations would be well supported by this.
>
Instead of cabal ghci -package $pkg you can do

    cabal v2-install $pkg1 --lib --package-env=foo
    cabal v2-install $pkg2 --lib --package-env=foo
    ...
    ghci -package-env=foo

Or alternatively

    cabal v2-repl -b $pkg

Unfortunately neither way is (known) bug free at the moment. I mostly
use the former, with the `default` package-env (then I can omit
--package-env flags) for all kind of experiments, e.g. to try out things
when answering people on `#haskell` or Stack Overflow; but I have my own
way to create environment file (i.e. I don't use v2-install --lib), as
cabal is atm not perfect, see Cabal's issue 5888. It's however important
to note, that `cabal` makes `ghc` ignore these global environments
(especially the default one) in builds etc, so `cabal v2-build` works.

> I suppose I somewhat agree with those who are calling for environment
> files to require a command-line flag. We've gone to all this trouble
> to make a nice stateless model for the package DB, but then we've
> lobbed a stateful UI on top of it, which seems odd and is clearly
> surprising a lot of people.

I disagree. I created `~/.ghci` and `~/.../environments/default` because
I want some defaults. Note: with v1-install people managed
user-package-db, with v2-install you are supposed to manage
environment(s). Yet, you can also only use `cabal v2-repl` or `cabal
v2-run` (See "new-run also supports running script files that ..." in
https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run).

Most of the above works (sans known bugs), and if you run Ubuntu, I
invite you to try it out, as it's easy to install from Herbert's PPA:
https://launchpad.net/~hvr/+archive/ubuntu/ghc

>
> Cheers
> Simon
>
> On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel
> mailto:hvrie...@gmail.com>> wrote:
>
> Matthew,
>
> I realize this to be a controversial issue, but what you're suggesting
> is effectively an attempt at cutting this cabal V2 feature off at
> the knees
> ("If Cabal won't change its default let's cripple this feature on
> GHC's
> side by rendering it pointless to use in cabal").
>
> If ghc environment aren't read anymore by default they fail to have
> the purpose they were invented for in the first place!
>
> At the risk of repeating things I've tried to explain already in the
> GitHub issue let me motivate (again) why we have these env files: We
> want to be able to provide a stateful interface providing the common
> idiom users from non-Nix UIs are 

Re: Proposal: Don't read environment files by default

[Simon Marlow]

I've also been surprised (not in a good way) by environment files. But I
haven't followed all the discussion so I still have some questions.

As I understand it, the aim is to support workflows like "cabal install
$pkg; ghci" (amongst other things). This currently works with 'cabal
install' because it installs into the global package DB, but it doesn't
work with 'cabal new-install' which installs into `~/.cabal/store`. Is the
plan that 'cabal new-install' will drop a .ghc-environment file in the
current directory, even outside of a cabal package/project? I would find
that *very* surprising as a user.

Indeed it almost works to say 'ghci -package-db
~/.cabal/store/ghc-8.4.3/package.db` after 'cabal new-install $pkg', but
this might fail if there are conflicts in the package DB preventing the use
of $pkg. GHC does some not-very-clever constraint solving to end up with a
consistent set of packages, and you can guide it by adding '-package $pkg'
flags. But it's still not very clever, and might fail.

Instead what if we had something like 'cabal ghci -package $pkg' to
indicate that you want to start GHCi with $pkg available? It would be
Cabal's job to ensure that $pkg was built and made available to GHCi. For
more complex cases, you can create a package or a project, but simple
ad-hoc invocations would be well supported by this.

I suppose I somewhat agree with those who are calling for environment files
to require a command-line flag. We've gone to all this trouble to make a
nice stateless model for the package DB, but then we've lobbed a stateful
UI on top of it, which seems odd and is clearly surprising a lot of people.

Cheers
Simon

On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel 
wrote:

> Matthew,
>
> I realize this to be a controversial issue, but what you're suggesting
> is effectively an attempt at cutting this cabal V2 feature off at the knees
> ("If Cabal won't change its default let's cripple this feature on GHC's
> side by rendering it pointless to use in cabal").
>
> If ghc environment aren't read anymore by default they fail to have
> the purpose they were invented for in the first place!
>
> At the risk of repeating things I've tried to explain already in the
> GitHub issue let me motivate (again) why we have these env files: We
> want to be able to provide a stateful interface providing the common
> idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
> already provided in the past; e.g.
>
>
> ,
> | $ cabal v1-install lens lens-aeson
> |
> | $ ghc --make MyProgUsingLens.hs
> | [1 of 1] ...
> | ...
> |
> | $ ghci
> | GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
> | Prelude> import Control.Lens
> | Prelude Control.Lens>
> `
>
> or similarly, when you had just `cabal v1-build` something, you'd get
> access to your projects dependencies which were installed into ghc's
> user pkg-db.
>
> This is also a workflow which has been well documented for over a decade
> in Haskell's literature and instructions *and* this is the same idiom as
> used by many popular package managers out there ("${pkgmgr} install
> somelibrary")
>
> So `cabal v1-build` made use of the user package-db facility to achieve
> this; but now with `cabal v2-build` the goal was to improve this
> workflow, but the user pkg-db facility wasn't a good fit anymore for the
> nix-style pkg store cache which can easily have dozens instances for the
> same lens-4.17 pkg-id cached (I just checked, I currently have 9
> instances of `lens-4.17` cached in my GHC 8.4.4 pkg store).
>
> So ghc environment files were born as a clever means to provide a
> thinned slice/view into the nix-style pkg store.
>
> And with these we can provide those workflows *without* the needed to pass
> extra flags or having to prefix each `ghc` invocation with `cabal
> repl`/`cabal exec`:
>
> ,
> | $ cabal v2-install --lib lens lens-aeson
> |
> | $ ghc --make MyProgUsingLens.hs
> | Loaded package environment from
> /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
> | [1 of 1] ...
> | ...
> |
> | $ ghci
> | GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
> | Loaded package environment from
> /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
> | Prelude> import Control.Lens
> | Prelude Control.Lens>
> `
>
> (and respectively for the `cabal v2-build` workflow)
>
> However, if we now had to explicitly pass a flag to ghc in order to have
> it pick up ghc env files, this would severly break this workflow
> everytime you forget about it, and it would certainly cause a lot of
> confusion (of e.g. users following instructions such as `cabal install
> lens` and then being confused that GHCi doesn't pick it up) and
> therefore a worse user experience for cabal users.
>
> Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6
> have been picking up ghc env files by default (and finally we've reached
> the point where the pkg-env-file-agnostic GHC versions are old enough to
> have moved ou

Re: Proposal: Don't read environment files by default

[Mikhail Glushenkov]

Hi *,

On Fri, 5 Apr 2019 at 12:09, Matthew Pickering
 wrote:
>
> [...]
>
> Therefore, it seems the correct course of action is to stop cabal
> generating the environment files by default. If user's still want to
> use them then they are easy to enable globally via a configuration
> setting.
>
> This can be achieved by adding the following to your "~/.cabal/config" file:
>
> write-ghc-environment-files: always

Please also note that this can be set per-project in the
'cabal.project' file. This is what we (Scrive AB) use to make ghcid
work out of the box for everyone in the team.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Matthew Pickering]

Thanks everyone for the lively discussion last week. I think we all
understand better now about environment files.

GHC reading environment files by default doesn't seem to be a problem
as it is just like having more packages installed in the global
package DB. This could be convenient.

The largest issue with the files is that cabal places relative paths
into the environment files which can easily become stale. For example,
by deleting the dist-newstyle directory. The absolute paths can also
become stale (as Richard discovered).

Therefore, it seems the correct course of action is to stop cabal
generating the environment files by default. If user's still want to
use them then they are easy to enable globally via a configuration
setting.

This can be achieved by adding the following to your "~/.cabal/config" file:

write-ghc-environment-files: always

The patch which changes the default behavior is here:

https://github.com/haskell/cabal/pull/5985

Cheers,

Matt

On Fri, Mar 29, 2019 at 4:53 PM Brandon Allbery  wrote:
>
> Nix instead of system, but roughly yes.
>
> On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus  wrote:
>>
>> To clarify: You mean different installations of same-version GHC? E.g.
>> /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
>> both happen to be 8.4.4 (so some other version)?
>>
>> - Oleg
>>
>> On 29.3.2019 5.44, Brandon Allbery wrote:
>> > FWIW I've run into this one myself, and use (clones, if necessary, of)
>> > v1 sandboxes for it currently.
>> >
>> > I've also been both bitten by, and helped by, environment files. The
>> > former is somewhat nastier, especially if you have multiple versions
>> > of ghc around and a given environment file was generated by a
>> > different ghc.
>> >
>> > I also have a somewhat weird setup, because of how I ended up cobbling
>> > this machine together: the global and user package dbs for my default
>> > ghc are more or less "owned" by xmonad development, anything else is
>> > in v2, a sandbox, or otherwise a different ghc version. Including nix,
>> > also operating as a sandbox (that is, I use an alias to set up nix
>> > within specific shells, rather than unconditionally loading its
>> > config). Plus that "default ghc" is via wrappers around hvr's ghc
>> > repos for Ubuntu. Which means I have lots of different ghcs around,
>> > depending on which shell window I'm in. Not that I'm expecting anyone
>> > to directly support this mess, but environment files seem to play
>> > especially badly with multiple ghc versions with different packages
>> > installed.
>> >
>> > On Thu, Mar 28, 2019 at 11:33 PM > > > wrote:
>> >
>> >
>> > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
>> >  escribió:
>> > >
>> >
>> > [...]
>> >
>> > > 2. I get pilloried every time I say it, but I vastly prefer
>> > global package databases to local ones.
>> >
>> > I'll second this in one specific context. v2-build has been
>> > amazing at work and in general for project-based development, but
>> > – and maybe simply because I don't know the right incantations – a
>> > step backwards for impromptu coding where I don't want to set up a
>> > whole project to start messing with an idea.
>> >
>> > I've actually fallen back to v1-install for this specific usecase:
>> > I have a set of ~15 packages, all installed from local git repos,
>> > some of which depend on others, that I *always* want when I'm in
>> > GHCi. It's basically my base. I may simply be doing it wrong but
>> > I've been unable to use the "global ghc.env file" trick successfully.
>> >
>> > Tom
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org 
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
>> >
>> > --
>> > brandon s allbery kf8nh
>> > allber...@gmail.com 
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Brandon Allbery]

Nix instead of system, but roughly yes.

On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus  wrote:

> To clarify: You mean different installations of same-version GHC? E.g.
> /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
> both happen to be 8.4.4 (so some other version)?
>
> - Oleg
>
> On 29.3.2019 5.44, Brandon Allbery wrote:
> > FWIW I've run into this one myself, and use (clones, if necessary, of)
> > v1 sandboxes for it currently.
> >
> > I've also been both bitten by, and helped by, environment files. The
> > former is somewhat nastier, especially if you have multiple versions
> > of ghc around and a given environment file was generated by a
> > different ghc.
> >
> > I also have a somewhat weird setup, because of how I ended up cobbling
> > this machine together: the global and user package dbs for my default
> > ghc are more or less "owned" by xmonad development, anything else is
> > in v2, a sandbox, or otherwise a different ghc version. Including nix,
> > also operating as a sandbox (that is, I use an alias to set up nix
> > within specific shells, rather than unconditionally loading its
> > config). Plus that "default ghc" is via wrappers around hvr's ghc
> > repos for Ubuntu. Which means I have lots of different ghcs around,
> > depending on which shell window I'm in. Not that I'm expecting anyone
> > to directly support this mess, but environment files seem to play
> > especially badly with multiple ghc versions with different packages
> > installed.
> >
> > On Thu, Mar 28, 2019 at 11:33 PM  > > wrote:
> >
> >
> > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
> >  escribió:
> > >
> >
> > [...]
> >
> > > 2. I get pilloried every time I say it, but I vastly prefer
> > global package databases to local ones.
> >
> > I'll second this in one specific context. v2-build has been
> > amazing at work and in general for project-based development, but
> > – and maybe simply because I don't know the right incantations – a
> > step backwards for impromptu coding where I don't want to set up a
> > whole project to start messing with an idea.
> >
> > I've actually fallen back to v1-install for this specific usecase:
> > I have a set of ~15 packages, all installed from local git repos,
> > some of which depend on others, that I *always* want when I'm in
> > GHCi. It's basically my base. I may simply be doing it wrong but
> > I've been unable to use the "global ghc.env file" trick successfully.
> >
> > Tom
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org 
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com 
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Iavor Diatchki]

Hi Richard,

For use case 1)  we should probably make GHCi be more robust, and make it
notice that an environment file has become unusable, say so, and ignore it,
rather than refusing to work.  It is a bit of an odd way to synchronize
build artifacts though.

For 2), I like global databases too, and I think that this system is very
compatible with it---you can think of the "global" environment as a default
project that GHCi uses when there is no other project around.  I believe
something like that is already being developed.  In the mean-time, however,
I've just been using one "sand-box" cabal project that has just a cabal
file, and no source files---when I want to try stuff out, I just go to that
project and fire up `ghci`.  It avoids cabal hell as you can easily control
the versions of the libraries you need, if you care.  It is also cool, in
that you can put it on github, and be able to easily recreate the same
environment on different machines.  And having used that for a while, I've
noticed that perhaps I don't really want a global project, as I've evolved
a couple of different "sand-boxes" for different topics that I commonly
play around with.

As for your relevant scenario:  couldn't you just add the packages you want
to use to your cabal file and ask it to build them for you?  Then you'd
know what version of the package you are actually experimenting with.  I
haven't actually run into this issue much, so I can't recall what GHCi says
if you try to use a module from a package that is not part of the current
context, but it sounds like we may want to improve its message, if the
current situation is confusing.




On Thu, Mar 28, 2019 at 12:26 PM Richard Eisenberg  wrote:

>
>
> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel 
> wrote:
>
> That being said, I'd be more interested to know the actual problems
> people are having
>
>
> I've run into two problems. I don't expect others to run into these
> particular problems, as my workflows are likely different than others', but
> both of these bit me independently.
>
> 1. I use two different machines regularly. I keep my files in sync between
> them using Dropbox. Yet, the Haskell installations between are not
> identical. Even if the GHC version is the same, it's quite likely that some
> library, etc., has been installed at a different version on the two
> machines. (Sometimes, even the GHC is different.) I did some work on a
> project on machine 1; this produced an environment file. Then, machine 2's
> window happened to be in the project directory. I wanted to spin up GHCi to
> check the type of, e.g., traverse. But GHCi wouldn't launch! This is
> because machine 1's work produced the environment file which invisibly got
> copied to machine 2 (via Dropbox) and then GHCi tried to respect the
> environment file, even though I had no interest in interacting with that
> particular project at the moment. Frustration and confusion ensued.
>
> 2. I get pilloried every time I say it, but I vastly prefer global package
> databases to local ones. This is because, usually, I'm compiling individual
> Haskell files and not projects. These Haskell files are snippets of code I
> look at in order to spot a GHC bug and files students email me seeking help
> on. I therefore like to build up a healthy set of libraries in my global
> package database so I can just test-drive these files, without worrying
> about managing dependencies. (It is true that I sometimes run into
> old-style "cabal hell", but I also accept that this is an unavoidable
> consequence of using the global package database. By the time this happens,
> a new GHC has been released anyway, and I use the outdated package database
> as an excuse to upgrade.)
>
>   The actual relevant scenario is this: I open GHCi to load some files
> from a project, and I want to experiment with them. But I realize that I
> want to import a few modules from packages not otherwise used in the
> project (e.g., the 'extra' package) in order to conduct my experiments. But
> I can't do this, because the env file tells me I can't. Frustration and
> confusion ensued.
>
> I have a better understanding of all this now -- and the knowledge to
> disable these features -- but this is how I came to dislike these env
> files. In both cases, it was because I wanted to interact with Haskell in a
> way that wasn't fully encapsulated within a project. Perhaps in a "real
> company", this wouldn't happen, but many Haskellers are not in real
> companies. :)
>
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Oleg Grenrus]

To clarify: You mean different installations of same-version GHC? E.g.
/opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which
both happen to be 8.4.4 (so some other version)?

- Oleg

On 29.3.2019 5.44, Brandon Allbery wrote:
> FWIW I've run into this one myself, and use (clones, if necessary, of)
> v1 sandboxes for it currently.
>
> I've also been both bitten by, and helped by, environment files. The
> former is somewhat nastier, especially if you have multiple versions
> of ghc around and a given environment file was generated by a
> different ghc.
>
> I also have a somewhat weird setup, because of how I ended up cobbling
> this machine together: the global and user package dbs for my default
> ghc are more or less "owned" by xmonad development, anything else is
> in v2, a sandbox, or otherwise a different ghc version. Including nix,
> also operating as a sandbox (that is, I use an alias to set up nix
> within specific shells, rather than unconditionally loading its
> config). Plus that "default ghc" is via wrappers around hvr's ghc
> repos for Ubuntu. Which means I have lots of different ghcs around,
> depending on which shell window I'm in. Not that I'm expecting anyone
> to directly support this mess, but environment files seem to play
> especially badly with multiple ghc versions with different packages
> installed.
>
> On Thu, Mar 28, 2019 at 11:33 PM  > wrote:
>
>
> > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
>  escribió:
> >
>
> [...]
>
> > 2. I get pilloried every time I say it, but I vastly prefer
> global package databases to local ones.
>
> I'll second this in one specific context. v2-build has been
> amazing at work and in general for project-based development, but
> – and maybe simply because I don't know the right incantations – a
> step backwards for impromptu coding where I don't want to set up a
> whole project to start messing with an idea.
>
> I've actually fallen back to v1-install for this specific usecase:
> I have a set of ~15 packages, all installed from local git repos,
> some of which depend on others, that I *always* want when I'm in
> GHCi. It's basically my base. I may simply be doing it wrong but
> I've been unable to use the "global ghc.env file" trick successfully.
>
> Tom
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> -- 
> brandon s allbery kf8nh
> allber...@gmail.com 
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Daniel Trstenjak]

Hi Herbert,

On Thu, Mar 28, 2019 at 08:33:41PM +0100, Herbert Valerio Riedel wrote:
> I'm a programmer. I'm very used to devel tooling I'm expected to invoke
> as a programmer to be affected by what's in scope as a function of the CWD,
> e.g. `cabal`, `git`, `make` to name a few.

I think the difference here is, that tools like 'git' create and use the
environment by themselves. So it's IMHO a lot easier to get an intuition
about the behaviour of these tools.

That's not the case for 'cabal' creating an environment and 'ghc' using it.

Greetings,
Daniel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Brandon Allbery]

FWIW I've run into this one myself, and use (clones, if necessary, of) v1
sandboxes for it currently.

I've also been both bitten by, and helped by, environment files. The former
is somewhat nastier, especially if you have multiple versions of ghc around
and a given environment file was generated by a different ghc.

I also have a somewhat weird setup, because of how I ended up cobbling this
machine together: the global and user package dbs for my default ghc are
more or less "owned" by xmonad development, anything else is in v2, a
sandbox, or otherwise a different ghc version. Including nix, also
operating as a sandbox (that is, I use an alias to set up nix within
specific shells, rather than unconditionally loading its config). Plus that
"default ghc" is via wrappers around hvr's ghc repos for Ubuntu. Which
means I have lots of different ghcs around, depending on which shell window
I'm in. Not that I'm expecting anyone to directly support this mess, but
environment files seem to play especially badly with multiple ghc versions
with different packages installed.

On Thu, Mar 28, 2019 at 11:33 PM  wrote:

>
> > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg 
> escribió:
> >
>
> [...]
>
> > 2. I get pilloried every time I say it, but I vastly prefer global
> package databases to local ones.
>
> I'll second this in one specific context. v2-build has been amazing at
> work and in general for project-based development, but – and maybe simply
> because I don't know the right incantations – a step backwards for
> impromptu coding where I don't want to set up a whole project to start
> messing with an idea.
>
> I've actually fallen back to v1-install for this specific usecase: I have
> a set of ~15 packages, all installed from local git repos, some of which
> depend on others, that I *always* want when I'm in GHCi. It's basically my
> base. I may simply be doing it wrong but I've been unable to use the
> "global ghc.env file" trick successfully.
>
> Tom
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allber...@gmail.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[amindfv]

> El 28 mar 2019, a las 3:26 PM, Richard Eisenberg  escribió:
> 

[...]

> 2. I get pilloried every time I say it, but I vastly prefer global package 
> databases to local ones.

I'll second this in one specific context. v2-build has been amazing at work and 
in general for project-based development, but – and maybe simply because I 
don't know the right incantations – a step backwards for impromptu coding where 
I don't want to set up a whole project to start messing with an idea.

I've actually fallen back to v1-install for this specific usecase: I have a set 
of ~15 packages, all installed from local git repos, some of which depend on 
others, that I *always* want when I'm in GHCi. It's basically my base. I may 
simply be doing it wrong but I've been unable to use the "global ghc.env file" 
trick successfully.

Tom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[lennart spitzner]

On 28/03/2019 13:24, Herbert Valerio Riedel wrote:
> [..] We
> want to be able to provide a stateful interface providing the common
> idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
> already provided in the past; [..]

On 28/03/2019 19:33, Michael Peyton Jones wrote:
> +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used
> by many other tools that handle this kind of thing. For example:
> - nix-shell
> - virtualenv
> - rbenv
> - sbt
> - jenv

On 28/03/2019 20:33, Herbert Valerio Riedel wrote:
> ..just because everyone else does it this way doesn't mean that it's the
> best way.. I'd argue it might be a sign of lack of imagination  ;-)


So we want to provide the common idiom users are used to, exactly up to
the point where we don't, at which point what users are used to suddenly
becomes irrelevant? Because.. imagination. Smileyface.


On 28/03/2019 13:24, Herbert Valerio Riedel wrote:
> However, if we now had to explicitly pass a flag to ghc in order to have
> it pick up ghc env files

False dichotomy. Matt's proposal was to make the feature opt-in. This
can, but need not be, via a commandline flag. There are other, less
obtrusive ways of allowing users to opt-in.

The behaviour of the cabal maintainers is hurtful to the ecosystem, and it
displays disrespect towards their own userbase. Herbert's arguments
presented in this thread are logically faulty. The cabal maintainers have
assumed an arrogant position of prescribing their perceived "best way"
despite overwhelming proof to the contrary.

+1 to Matt's proposal

-- lennart
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

On 2019-03-28 at 18:33:58 +, Michael Peyton Jones wrote:
> +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used
> by many other tools that handle this kind of thing. For example:

..just because everyone else does it this way doesn't mean that it's the
best way.. I'd argue it might be a sign of lack of imagination  ;-)

In fact, personally I never liked `virtualenv` much as it required me

[...]

> The advantage is that the scoping of the special configuration is very
> clear: it's the shell that the command launches. Programmers are very used
> to this, and changes in shell environments are expected to change the
> behaviour of programs.

I'm a programmer. I'm very used to devel tooling I'm expected to invoke
as a programmer to be affected by what's in scope as a function of the CWD,
e.g. `cabal`, `git`, `make` to name a few.

And to me GHCi falls into the same category, it's a tool I'm expected to
interact directly with -- otherwisw it's CLI would be designed a lot
different; as a matter fact it's been supported for ages to pick up a
`.ghci` by walking up your fs system starting at CWD until one is found...
So there's clearly precedent for the logical next step that ghc env
files represent...

> Plus, as functional programmers this is just the sort of idiom we use all
> the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`.

Sure, but then again, we're talking about the unix shell which leans
towards different idioms than the functional programming paradigm; and
insisting to impose one paradigm on a language which isn't rooted in
that paradigm is often not a good idea either...

> On the negative side: I've helped ~6 people at my company alone debug
> issues due to environment files.

Which GHC versions was this with?

[...]

> *However*, I think Herbert is quite right that this particular proposal
> amounts to "remove this feature". The following might be a compromise
> solution: we can introduce `cabal ghc` as a parallel feature, and then in a
> few releases we can assess the popularity of the two approaches, and
> potentially stop generating environment files from Cabal if people aren't
> using them.
>
> I think there are enough people that feel strongly about environment files
> that we could get together the manpower to write `cabal ghc`.

Sure, but this totally misses the point. We already have `cabal ghc` but
the point was (as Duncan also pointed out in an earlier reply) to *not*
have to require cabal as a middleman.

I want to be able to invoke `ghc` and `ghci` directly, without having to
invoke `cabal` everytime. If I wanted to always invoke `cabal ghci` I
wouldn't have needed to invest time to help with the ghc-env
feature... ;-)

>> This is also a workflow which has been well documented for over a decade
>> in Haskell's literature and instructions *and* this is the same idiom as
>> used by many popular package managers out there ("${pkgmgr} install
>> somelibrary")
>
> This is an interesting bit of background. FWIW, I would feel a lot better
> about this feature if it wasn't a side-effect of `cabal build`. If you had
> to run `cabal
> save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects`
> that wouldn't bother me (I still wouldn't use it, though). The current
> situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`,
> which is a bit surprising.

You can tweak your global cabal config to have `cabal` behave just like
that, i.e. then you'd have to explictly opt-in either by writing

  write-ghc-environment-files: always

into your current `cabal.project` configuration, or pass it adhoc on the
CLI

  cabal v2-build --write-ghc-environment-files=always

and as outlined earlier, the per-user env-files (which are picked up
when you are *not* in any project context) are already explicitly
managed (i.e. you have to explcitly invoke `cabal v2-install` to have
them be created/modified)


PS: There's two categories of pkg-env files (the per-HOME ones and the
per-CWD ones) and I'm not sure if people are only complaining about
the CWD ones or also the HOME ones...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Richard Eisenberg]

> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel  
> wrote:
> 
> That being said, I'd be more interested to know the actual problems
> people are having

I've run into two problems. I don't expect others to run into these particular 
problems, as my workflows are likely different than others', but both of these 
bit me independently.

1. I use two different machines regularly. I keep my files in sync between them 
using Dropbox. Yet, the Haskell installations between are not identical. Even 
if the GHC version is the same, it's quite likely that some library, etc., has 
been installed at a different version on the two machines. (Sometimes, even the 
GHC is different.) I did some work on a project on machine 1; this produced an 
environment file. Then, machine 2's window happened to be in the project 
directory. I wanted to spin up GHCi to check the type of, e.g., traverse. But 
GHCi wouldn't launch! This is because machine 1's work produced the environment 
file which invisibly got copied to machine 2 (via Dropbox) and then GHCi tried 
to respect the environment file, even though I had no interest in interacting 
with that particular project at the moment. Frustration and confusion ensued.

2. I get pilloried every time I say it, but I vastly prefer global package 
databases to local ones. This is because, usually, I'm compiling individual 
Haskell files and not projects. These Haskell files are snippets of code I look 
at in order to spot a GHC bug and files students email me seeking help on. I 
therefore like to build up a healthy set of libraries in my global package 
database so I can just test-drive these files, without worrying about managing 
dependencies. (It is true that I sometimes run into old-style "cabal hell", but 
I also accept that this is an unavoidable consequence of using the global 
package database. By the time this happens, a new GHC has been released anyway, 
and I use the outdated package database as an excuse to upgrade.)

  The actual relevant scenario is this: I open GHCi to load some files from a 
project, and I want to experiment with them. But I realize that I want to 
import a few modules from packages not otherwise used in the project (e.g., the 
'extra' package) in order to conduct my experiments. But I can't do this, 
because the env file tells me I can't. Frustration and confusion ensued.

I have a better understanding of all this now -- and the knowledge to disable 
these features -- but this is how I came to dislike these env files. In both 
cases, it was because I wanted to interact with Haskell in a way that wasn't 
fully encapsulated within a project. Perhaps in a "real company", this wouldn't 
happen, but many Haskellers are not in real companies. :)

Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Phyx]

> I am quite confused as to how people are using `ghci` without loading the
environment files, at least in the context of cabal v2 (aka "new cabal").
 When you run `ghci` on its own, unless you load an environment file, you
would only have access to globally installed packages, which is almost
never what you want.   What is the workflow that this proposal optimizes?

That's precisely how I use ghci. In quite a few of my use-cases all I care
or want are the boot libraries and nothing else. I can appreciate that I
may not be the common case here but I definitely use it this way.

I'm agnostic on whether this change or not of reading the environment files
by default. But I am very much against the cabal ghci or cabal ghc
interfaces. It's one of the things I loathe the most about stack. I don't
care what the compiler does by default on his own but I don't want to add
another layer to the onion.

I find this very hard to debug. Perhaps cabal should just ask you what you
want the first time and that'll be your default.

Tamar

Sent from my Mobile

On Thu, Mar 28, 2019, 18:10 Iavor Diatchki  wrote:

> I am quite confused as to how people are using `ghci` without loading the
> environment files, at least in the context of cabal v2 (aka "new cabal").
>  When you run `ghci` on its own, unless you load an environment file, you
> would only have access to globally installed packages, which is almost
> never what you want.   What is the workflow that this proposal optimizes?
>
> The default behavior should be what's commonly useful and, in my
> experience, when I run GHCi in the context of a project, I pretty much
> always want it to load the environment associated with the project.   It is
> incredibly useful when you are working on a project where there are
> multiple broken modules (e.g., during refactoring), and you want to fix
> them one at a time, in the order that makes sense to you.
>
> -Iavor
>
>
> On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson 
> wrote:
>
>> On 28/03/2019 14.58, Oleg Grenrus wrote:
>> > There is. Add
>> >
>> > write-ghc-environment-files: never
>> >
>> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.
>> >
>>
>> That doesn't really work if you actually want to be able to use both
>> ways of working, does it? That same thing applies to
>>
>>   export GHC_ENVIRONMENT=-
>>
>> which someone else posted, but at least that can be done by tooling
>> before invoking ghc. It's odd to have to change a global setting to
>> avoid this. (However, thanks for the hints -- I'll be setting that
>> GHC_ENVIRONMENT from now on.)
>>
>> +1 for changing the default.
>>
>> It seems really weird to force other tooling to opt out when this could
>> easily be solved by just having
>>
>>cabal ghci
>>cabal ghc
>>
>> commands which set up the environment properly and tell users to use
>> that if they want to use cabal's environment files. FWIW, I also see
>> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
>> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
>> something users should really be running unless they know what they're
>> doing *and* it should be as tooling-friendly as possible.
>>
>> Regards,
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

On 2019-03-28 at 18:22:12 +, Duncan Coutts wrote:

> The intention was to not force everyone to use "stack ghci" and "cabal
> ghci" all the time, 

And it's important to note that those who *want* to be forced to "cabal
ghci" all the time, can still subject themselves to that idiom by
configuring their cabal installation accordingly.

However, the point here is that there's also those of us who don't want
to be denied the ability to *not* be forced to use that idiom, and
instead use the CWD-sensitive idiom which nobody complains about when
using Git or make.

With GHC/Cabal as it stands we are ahead of other ecosystems as we're in
the advantageous position to be able to support *more* workflows than
other ecosystems can support.

IMO we should embrace and leverage the flexibility rather than to trying
to artificially limit our possibilities just because we're doing
something different. I mean, with that attitude we can just stop trying
to do anything new... ;-)

> Perhaps the next best thing is a "cabal shell" feature, that enters a
> new system shell environment where ghc/ghci etc do pick up the project
> environment.

We already have this don't we? That's basically what `cabal v2-exec`
does; but having to remember to invoke `cabal v2-exec bash` to enter a
sub-shell is basically just a variant of "force everyone to use "cabal
ghci" all the time where you have to go through cabal as a middleman
even though you shouldn't have to.

Don't get me wrong, it's good that we have `cabal v2-exec` as yet
another tool in our toolbox and it can do a few extra things in that
workflow and is useful for those who have opt-ed out of the automatic
per-project CWD-driven-env-file management; *however*, it doesn't meet
the needs for workflows of being able to invoke `ghci` without cursing
like a sailor every time we end up in a useless GHCi session because we
forgot to throw ourselves into a `cabal v2-exec` subshell in our n-th
xterm (or [1]) even though other tooling like `make` or `git` which I'm
used to as a developer does the right thing because they honor the
common DWIM design principle/idiom for shell-oriented tooling...

That being said, I'd be more interested to know the actual problems
people are having and trying to address those without throwing the baby
out with the bathwater, cause I think many of the problems are of the
XY-problem variety here or simply because we did a terrible job at
explaining, providing tutorials, or documenting how this feature works,
what it is and what it isn't, how it can be used, and what cool new
workflows are at our disposal with the upcoming major cabal 3.0
milestone...


[1]: ...or even worse, being in the *wrong* subshell while you've
 already `cd`ed to a different project folder... imagine the amount
 of cursing you'd exhibit wondering for 5 minutes before you notice
 you're picking up another project's pkg env...


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Michael Peyton Jones]

+1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used
by many other tools that handle this kind of thing. For example:
- nix-shell
- virtualenv
- rbenv
- sbt
- jenv

The advantage is that the scoping of the special configuration is very
clear: it's the shell that the command launches. Programmers are very used
to this, and changes in shell environments are expected to change the
behaviour of programs.

Plus, as functional programmers this is just the sort of idiom we use all
the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`.

On the negative side: I've helped ~6 people at my company alone debug
issues due to environment files. Two of those were novice users (the people
whom this feature is supposed to help). In my experience it breaks people's
assumptions about what sort of things influence compiler invocations.
People don't expect a stateful dependency from a previous run of a build
tool to a later run of a lower-level compiler. Moreover, the failures can
be mystifying, and I was only able to help because I already knew "get rid
of any environment files" as a solution to "weird dependency issues".

*However*, I think Herbert is quite right that this particular proposal
amounts to "remove this feature". The following might be a compromise
solution: we can introduce `cabal ghc` as a parallel feature, and then in a
few releases we can assess the popularity of the two approaches, and
potentially stop generating environment files from Cabal if people aren't
using them.

I think there are enough people that feel strongly about environment files
that we could get together the manpower to write `cabal ghc`.

> This is also a workflow which has been well documented for over a decade
in Haskell's literature and instructions *and* this is the same idiom as
used by many popular package managers out there ("${pkgmgr} install
somelibrary")

This is an interesting bit of background. FWIW, I would feel a lot better
about this feature if it wasn't a side-effect of `cabal build`. If you had
to run `cabal
save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects`
that wouldn't bother me (I still wouldn't use it, though). The current
situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`,
which is a bit surprising.

M

On Thu, Mar 28, 2019 at 5:02 PM Bardur Arantsson 
wrote:

> On 28/03/2019 14.58, Oleg Grenrus wrote:
> > There is. Add
> >
> > write-ghc-environment-files: never
> >
> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.
> >
>
> That doesn't really work if you actually want to be able to use both
> ways of working, does it? That same thing applies to
>
>   export GHC_ENVIRONMENT=-
>
> which someone else posted, but at least that can be done by tooling
> before invoking ghc. It's odd to have to change a global setting to
> avoid this. (However, thanks for the hints -- I'll be setting that
> GHC_ENVIRONMENT from now on.)
>
> +1 for changing the default.
>
> It seems really weird to force other tooling to opt out when this could
> easily be solved by just having
>
>cabal ghci
>cabal ghc
>
> commands which set up the environment properly and tell users to use
> that if they want to use cabal's environment files. FWIW, I also see
> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
> something users should really be running unless they know what they're
> doing *and* it should be as tooling-friendly as possible.
>
> Regards,
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Vanessa McHale]

I use cabal new-repl.

I actually kind of like having GHC environment files (maybe not as a
default) but they remind me of "vim turds" in that they end up littering
your projects.

Cheers,
Vanessa McHale

On 3/28/19 1:09 PM, Iavor Diatchki wrote:
> I am quite confused as to how people are using `ghci` without loading
> the environment files, at least in the context of cabal v2 (aka "new
> cabal").   When you run `ghci` on its own, unless you load an
> environment file, you would only have access to globally installed
> packages, which is almost never what you want.   What is the workflow
> that this proposal optimizes?
>
> The default behavior should be what's commonly useful and, in my
> experience, when I run GHCi in the context of a project, I pretty much
> always want it to load the environment associated with the project. 
>  It is incredibly useful when you are working on a project where there
> are multiple broken modules (e.g., during refactoring), and you want
> to fix them one at a time, in the order that makes sense to you.
>
> -Iavor
>
>
> On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson
> mailto:s...@scientician.net>> wrote:
>
> On 28/03/2019 14.58, Oleg Grenrus wrote:
> > There is. Add
> >
> >     write-ghc-environment-files: never
> >
> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0
> or later.
> >
>
> That doesn't really work if you actually want to be able to use both
> ways of working, does it? That same thing applies to
>
>   export GHC_ENVIRONMENT=-
>
> which someone else posted, but at least that can be done by tooling
> before invoking ghc. It's odd to have to change a global setting to
> avoid this. (However, thanks for the hints -- I'll be setting that
> GHC_ENVIRONMENT from now on.)
>
> +1 for changing the default.
>
> It seems really weird to force other tooling to opt out when this
> could
> easily be solved by just having
>
>    cabal ghci
>    cabal ghc
>
> commands which set up the environment properly and tell users to use
> that if they want to use cabal's environment files. FWIW, I also see
> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
> something users should really be running unless they know what they're
> doing *and* it should be as tooling-friendly as possible.
>
> Regards,
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Duncan Coutts]

As one of the culprits who implemented this idea in ghc and cabal the
first place, I think that if it turns out this is just too surprising
for everyone then we should indeed change the default, and provide
another easy way to use it.

The intention of course is exactly what Iavor described:

> The default behavior should be what's commonly useful and, in my
> experience, when I run GHCi in the context of a project, I pretty
> much always want it to load the environment associated with the
> project.   It is incredibly useful when you are working on a project
> where there are multiple broken modules (e.g., during refactoring),
> and you want to fix them one at a time, in the order that makes sense
> to you.

The intention was to not force everyone to use "stack ghci" and "cabal
ghci" all the time, and for tutorials etc that just say "ghci" to
actually work. It's nice to be able to work with those tools directly.
Afterall, they're not that low level (like gcc); ghc/ghci have --make
functionality built in and can be used directly (i.e. without a ton of
flags).

But fair enough, there seems to be a very large number of users where
this behaviour is surprising, including reports I hear about the intro
tutorial setting.

Perhaps the next best thing is a "cabal shell" feature, that enters a
new system shell environment where ghc/ghci etc do pick up the project
environment.

This would rely on ghc continuing to use the environment variables to
select an package file, but we could disable ghc reading the files by
default.

Thoughts?

On Thu, 2019-03-28 at 10:08 +, Matthew Pickering wrote:
> Hi all,
> 
> Environment files have caused a large amount of pain for users
> because
> they are read by default by GHC.
> 
> For example: https://github.com/haskell/cabal/issues/4542
> 
> Cabal developers have indicated that they are not going to stop
> generating them by default despite the overwhelming user pressure.
> 
> Therefore I propose that users should opt-in to using environment
> files by having to explicitly pass a flag to enable the search
> behavior.
> 
> This will provide a much better user experience overall and will stop
> tooling having to isolate itself from their existence.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Iavor Diatchki]

I am quite confused as to how people are using `ghci` without loading the
environment files, at least in the context of cabal v2 (aka "new cabal").
 When you run `ghci` on its own, unless you load an environment file, you
would only have access to globally installed packages, which is almost
never what you want.   What is the workflow that this proposal optimizes?

The default behavior should be what's commonly useful and, in my
experience, when I run GHCi in the context of a project, I pretty much
always want it to load the environment associated with the project.   It is
incredibly useful when you are working on a project where there are
multiple broken modules (e.g., during refactoring), and you want to fix
them one at a time, in the order that makes sense to you.

-Iavor


On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson 
wrote:

> On 28/03/2019 14.58, Oleg Grenrus wrote:
> > There is. Add
> >
> > write-ghc-environment-files: never
> >
> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.
> >
>
> That doesn't really work if you actually want to be able to use both
> ways of working, does it? That same thing applies to
>
>   export GHC_ENVIRONMENT=-
>
> which someone else posted, but at least that can be done by tooling
> before invoking ghc. It's odd to have to change a global setting to
> avoid this. (However, thanks for the hints -- I'll be setting that
> GHC_ENVIRONMENT from now on.)
>
> +1 for changing the default.
>
> It seems really weird to force other tooling to opt out when this could
> easily be solved by just having
>
>cabal ghci
>cabal ghc
>
> commands which set up the environment properly and tell users to use
> that if they want to use cabal's environment files. FWIW, I also see
> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
> something users should really be running unless they know what they're
> doing *and* it should be as tooling-friendly as possible.
>
> Regards,
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Bardur Arantsson]

On 28/03/2019 14.58, Oleg Grenrus wrote:
> There is. Add
> 
>     write-ghc-environment-files: never
> 
> to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.
> 

That doesn't really work if you actually want to be able to use both
ways of working, does it? That same thing applies to

  export GHC_ENVIRONMENT=-

which someone else posted, but at least that can be done by tooling
before invoking ghc. It's odd to have to change a global setting to
avoid this. (However, thanks for the hints -- I'll be setting that
GHC_ENVIRONMENT from now on.)

+1 for changing the default.

It seems really weird to force other tooling to opt out when this could
easily be solved by just having

   cabal ghci
   cabal ghc

commands which set up the environment properly and tell users to use
that if they want to use cabal's environment files. FWIW, I also see
e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas
e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not
something users should really be running unless they know what they're
doing *and* it should be as tooling-friendly as possible.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Iavor Diatchki]

I used to be confused by the environment files too until I figured out what
they are, and now I use them all the time.

It is really nice to be able to have the "old fashioned" way of just
running ghci and having it be aware of the current project your are in.

To me, it really makes sense to be aware of the context by default.  To
reduce confusion, we could make GHCi be more explicit about telling the
user that it loaded a context, but I think 99% of the time I want it to so.
So I'd prefer to have a flag to disable the behavior for the 1%, but the
default should load the context IMHO

Iavor




On Thu, Mar 28, 2019, 08:49 Richard Eisenberg  wrote:

>
>
> On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel 
> wrote:
>
> I for one would hate to remove what I consider a useful feature
>
>
> I don't see anyone is asking for a feature removal here. This thread seems
> to be more about how to set a default.
>
> I personally find it surprising for a tool like a compiler to be
> directory-sensitive. But I've now learned that with `export
> GHC_ENVIRONMENT=-` in my profile, my compiler indeed isn't
> directory-sensitive. Furthermore, I've learned how to suppress the env
> files entirely with `write-ghc-environment-files: never` in my
> ~/.cabal/config. So I'm not actually all too bothered by this anymore. I
> retain my opinion that directory-sensitivity is a poor design (it's
> precisely what threw me off Stack the first time I tried it) for
> compiler-like tools, but perhaps that ship has sailed, as I agree that
> changing this now may lead to a poor user experience.
>
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Richard Eisenberg]

> On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel  
> wrote:
> 
> I for one would hate to remove what I consider a useful feature

I don't see anyone is asking for a feature removal here. This thread seems to 
be more about how to set a default.

I personally find it surprising for a tool like a compiler to be 
directory-sensitive. But I've now learned that with `export GHC_ENVIRONMENT=-` 
in my profile, my compiler indeed isn't directory-sensitive. Furthermore, I've 
learned how to suppress the env files entirely with 
`write-ghc-environment-files: never` in my ~/.cabal/config. So I'm not actually 
all too bothered by this anymore. I retain my opinion that 
directory-sensitivity is a poor design (it's precisely what threw me off Stack 
the first time I tried it) for compiler-like tools, but perhaps that ship has 
sailed, as I agree that changing this now may lead to a poor user experience.

Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

On 2019-03-28 at 15:55:01 +0200, Bryan Richter wrote:

[...]

> If we want Nix-style builds, let's do them Nix style, and use a shell.

Cabal supports multiple workflows/idioms. Sometimes you want a transient
sub-shell (which is the one you're e.g. limited to when using Stack),
while sometimes you want to use cabal to set up an implicit stateful
environment after which you want cabal to be completely out of the
picture and operate in a non-Nix-style idiom...

I for one would hate to remove what I consider a useful feature (which I
happen to use a lot myself and I also show it off when teaching Haskell;
and which we spent a lot of effort designing and implementing in ghc and
cabal over the last couple years...) just to satisfy another group of
people who don't appreciate it and request that those who like it shall
not have it anymore... :-/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Oleg Grenrus]

There is. Add

    write-ghc-environment-files: never

to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later.

- Oleg

On 28.3.2019 15.49, Richard Eisenberg wrote:
> I have spent quite a bit of time debugging this issue, being utterly 
> surprised about the existence of these files. Furthermore, until today, I had 
> been unable to find a way to turn the feature off. I now understand 
> (https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an 
> undocumented mechanism for doing so in GHC. It's still frustrating that there 
> is no similar mechanism to globally (i.e., in ~/.cabal/config) disable these 
> files in cabal.
>
> While I expect "project-based" tools to care about their directory (e.g., 
> git, cabal, stack), I would never expect a compiler (which is intended to be 
> a low-level utility) to do so.
>
> Richard
>
>> On Mar 28, 2019, at 6:08 AM, Matthew Pickering  
>> wrote:
>>
>> Hi all,
>>
>> Environment files have caused a large amount of pain for users because
>> they are read by default by GHC.
>>
>> For example: https://github.com/haskell/cabal/issues/4542
>>
>> Cabal developers have indicated that they are not going to stop
>> generating them by default despite the overwhelming user pressure.
>>
>> Therefore I propose that users should opt-in to using environment
>> files by having to explicitly pass a flag to enable the search
>> behavior.
>>
>> This will provide a much better user experience overall and will stop
>> tooling having to isolate itself from their existence.
>>
>> Cheers,
>>
>> Matt
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Bryan Richter]

I am +1 on not reading them by default. I dislike implicit configuration
(that's enough reason there), and it interacts poorly with other tools that
use ghc.

Like Richard Eisenberg, I also think of ghc as a low-level utility, but I
recognize that intuition is already wrong in various ways. (ghc is really
quite clever.) For me that's not reason enough to disable this.

The tight coupling with Cabal, however, seems unwise, and implicit
configuration seems like something from the 20th century.

If we want Nix-style builds, let's do them Nix style, and use a shell.

On Thu, Mar 28, 2019 at 3:50 PM Richard Eisenberg  wrote:

> I have spent quite a bit of time debugging this issue, being utterly
> surprised about the existence of these files. Furthermore, until today, I
> had been unable to find a way to turn the feature off. I now understand (
> https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an
> undocumented mechanism for doing so in GHC. It's still frustrating that
> there is no similar mechanism to globally (i.e., in ~/.cabal/config)
> disable these files in cabal.
>
> While I expect "project-based" tools to care about their directory (e.g.,
> git, cabal, stack), I would never expect a compiler (which is intended to
> be a low-level utility) to do so.
>
> Richard
>
> > On Mar 28, 2019, at 6:08 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
> >
> > Hi all,
> >
> > Environment files have caused a large amount of pain for users because
> > they are read by default by GHC.
> >
> > For example: https://github.com/haskell/cabal/issues/4542
> >
> > Cabal developers have indicated that they are not going to stop
> > generating them by default despite the overwhelming user pressure.
> >
> > Therefore I propose that users should opt-in to using environment
> > files by having to explicitly pass a flag to enable the search
> > behavior.
> >
> > This will provide a much better user experience overall and will stop
> > tooling having to isolate itself from their existence.
> >
> > Cheers,
> >
> > Matt
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Richard Eisenberg]

I have spent quite a bit of time debugging this issue, being utterly surprised 
about the existence of these files. Furthermore, until today, I had been unable 
to find a way to turn the feature off. I now understand 
(https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an undocumented 
mechanism for doing so in GHC. It's still frustrating that there is no similar 
mechanism to globally (i.e., in ~/.cabal/config) disable these files in cabal.

While I expect "project-based" tools to care about their directory (e.g., git, 
cabal, stack), I would never expect a compiler (which is intended to be a 
low-level utility) to do so.

Richard

> On Mar 28, 2019, at 6:08 AM, Matthew Pickering  
> wrote:
> 
> Hi all,
> 
> Environment files have caused a large amount of pain for users because
> they are read by default by GHC.
> 
> For example: https://github.com/haskell/cabal/issues/4542
> 
> Cabal developers have indicated that they are not going to stop
> generating them by default despite the overwhelming user pressure.
> 
> Therefore I propose that users should opt-in to using environment
> files by having to explicitly pass a flag to enable the search
> behavior.
> 
> This will provide a much better user experience overall and will stop
> tooling having to isolate itself from their existence.
> 
> Cheers,
> 
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: Don't read environment files by default

[Herbert Valerio Riedel]

Matthew,

I realize this to be a controversial issue, but what you're suggesting
is effectively an attempt at cutting this cabal V2 feature off at the knees
("If Cabal won't change its default let's cripple this feature on GHC's
side by rendering it pointless to use in cabal").

If ghc environment aren't read anymore by default they fail to have
the purpose they were invented for in the first place!

At the risk of repeating things I've tried to explain already in the
GitHub issue let me motivate (again) why we have these env files: We
want to be able to provide a stateful interface providing the common
idiom users from non-Nix UIs are used to, and which `cabal` and `ghc`
already provided in the past; e.g.


,
| $ cabal v1-install lens lens-aeson
| 
| $ ghc --make MyProgUsingLens.hs
| [1 of 1] ...
| ...
| 
| $ ghci
| GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
| Prelude> import Control.Lens
| Prelude Control.Lens> 
`

or similarly, when you had just `cabal v1-build` something, you'd get
access to your projects dependencies which were installed into ghc's
user pkg-db.

This is also a workflow which has been well documented for over a decade
in Haskell's literature and instructions *and* this is the same idiom as
used by many popular package managers out there ("${pkgmgr} install
somelibrary")

So `cabal v1-build` made use of the user package-db facility to achieve
this; but now with `cabal v2-build` the goal was to improve this
workflow, but the user pkg-db facility wasn't a good fit anymore for the
nix-style pkg store cache which can easily have dozens instances for the
same lens-4.17 pkg-id cached (I just checked, I currently have 9
instances of `lens-4.17` cached in my GHC 8.4.4 pkg store).

So ghc environment files were born as a clever means to provide a
thinned slice/view into the nix-style pkg store.

And with these we can provide those workflows *without* the needed to pass
extra flags or having to prefix each `ghc` invocation with `cabal
repl`/`cabal exec`:

,
| $ cabal v2-install --lib lens lens-aeson
| 
| $ ghc --make MyProgUsingLens.hs
| Loaded package environment from 
/home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
| [1 of 1] ...
| ...
|
| $ ghci
| GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
| Loaded package environment from 
/home/hvr/.ghc/x86_64-linux-8.4.4/environments/default
| Prelude> import Control.Lens
| Prelude Control.Lens> 
`

(and respectively for the `cabal v2-build` workflow)

However, if we now had to explicitly pass a flag to ghc in order to have
it pick up ghc env files, this would severly break this workflow
everytime you forget about it, and it would certainly cause a lot of
confusion (of e.g. users following instructions such as `cabal install
lens` and then being confused that GHCi doesn't pick it up) and
therefore a worse user experience for cabal users.

Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6
have been picking up ghc env files by default (and finally we've reached
the point where the pkg-env-file-agnostic GHC versions are old enough to
have moved outside the traditional 3-5 major ghc release
support-windows!), and now you'd have to remember which GHC versions
don't do this anymore and instead require passing an additional
flag. This would IMO translate to a terrible user experience.

And also tooling would still need to have the logic to "isolate
themselves" for those versions of GHC that picked up env files by
default unless they dropped support for older versions. Also, how much
tooling is there even that needs to be aware of this and how did it cope
with GHC's user pkg db which can easily screw up things as well by
providing a weird enough pkg-db env! And why is it considered such a big
burden for tooling to invoke GHC in a robust enough way to not be
confused by the user's configuration? IMO, shifting the cost of passing
an extra flag to a tool which doesn't feel any pain is the better
tradeoff than to inconvience all cabal users to have rememeber to pass
an additional flag for what is designed to be the default UI/workflow
idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix
environment which already controls environment vars can easily override
GHC's or cabal's defaults to tailor them more towards Nix's specific
assumptions/requirements.


Long story short, I'm -1 on changing GHC's default as the resulting
downsides clearly outweight IMO.


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Proposal: Don't read environment files by default

[Matthew Pickering]

Hi all,

Environment files have caused a large amount of pain for users because
they are read by default by GHC.

For example: https://github.com/haskell/cabal/issues/4542

Cabal developers have indicated that they are not going to stop
generating them by default despite the overwhelming user pressure.

Therefore I propose that users should opt-in to using environment
files by having to explicitly pass a flag to enable the search
behavior.

This will provide a much better user experience overall and will stop
tooling having to isolate itself from their existence.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs