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
Ben Gamari writes:
> Shayne Fletcher via ghc-devs writes:
>
>> Hi,
>>
>> It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage?
>>
> Yes, I just sent notification of this. A routine service restart ended
> up going wrong. In touch with our infrastructure company's support
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
Shayne Fletcher via ghc-devs writes:
> Hi,
>
> It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage?
>
Yes, I just sent notification of this. A routine service restart ended
up going wrong. In touch with our infrastructure company's support team.
More updates coming soon.
Hi everyone,
Due to unplanned maintenance gitlab.haskell.org is currently down. Sorry
for the inconvenience. I'll post updates as appropriate.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage?
--
Shayne Fletcher
Language Engineer
c: +1 917 699 7763
e: shayne.fletc...@daml.com
Digital Asset Holdings, LLC
4 World Trade Center150 Greenwich
Street, 47th Floor
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
I've started a wiki page to document some of this discussion
https://gitlab.haskell.org/ghc/ghc/wikis/Developing-Hadrian. We'll also
need to deal with ouputs as well as inputs (dependencies) soon. Hence
I've expanded a bit on my understanding of rule *outputs* and added the
terms "vital input"
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
22 matches
Mail list logo
