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
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).
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'
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.
>
>
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
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)?
>
> -
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,
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,
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
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
> 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
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
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
> 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
> 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
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
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
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
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
> 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
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
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
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
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
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
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
26 matches
Mail list logo
