Proposal: Don't read environment files by default

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel-3
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Richard Eisenberg-5
In reply to this post by Matthew Pickering
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Bryan Richter-2
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Oleg Grenrus
In reply to this post by Richard Eisenberg-5
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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel-3
In reply to this post by Bryan Richter-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Richard Eisenberg-5


On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:


On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson-2
In reply to this post by Oleg Grenrus
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Duncan Coutts-3
In reply to this post by Matthew Pickering
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 +0000, 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Vanessa McHale
In reply to this post by Iavor Diatchki

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Peyton Jones
In reply to this post by Bardur Arantsson-2
+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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel-3
In reply to this post by Duncan Coutts-3
On 2019-03-28 at 18:22:12 +0000, 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Phyx
In reply to this post by 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?

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Richard Eisenberg-5
In reply to this post by Herbert Valerio Riedel-3


On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel-3
In reply to this post by Michael Peyton Jones
On 2019-03-28 at 18:33:58 +0000, 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

lennart spitzner-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

amindfv
In reply to this post by Richard Eisenberg-5

> El 28 mar 2019, a las 3:26 PM, Richard Eisenberg <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:

> El 28 mar 2019, a las 3:26 PM, Richard Eisenberg <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
12