On 16-09-13 12:07, Theodore Lief Gannon wrote:

Stack *does* allow direct interaction with GHC:

stack exec -- ghc version

I find `stack ghc -- --version` to be a bit easier. Anything after the `--` is passed as an argument to ghc. From the help documentation: stack ghc -- X.hs -o x

Granted this lacks a bit in brevity, but if you want to issue multiple commands from "inside" stack's private environment, you can also just do this:

stack exec sh

On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg wrote:

...

I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it.

My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it.

My approach:

1. `brew install haskell-stack`. Success.

At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to

2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including

...

Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc Right Nothing

At the end, I am helpfully told

...

To use this GHC and packages outside of a project, consider using: stack ghc, stack ghci, stack runghc, or stack exec

So I then

3. `stack ghci`. My computer’s first reaction is to say

...

Run from outside a project, using implicit global project config Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml Error parsing targets: The specified targets matched no packages. Perhaps you need to run 'stack init'? Warning: build failed, but optimistically launching GHCi anyway

which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected.

Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I

4. `stack ghc --version`. This command reports

...

Invalid option `--version’

Grumble. It seems I can’t interact with GHC directly.

————

At this point, I am reminded why I dislike stack:

**It’s optimized for a different workflow than I use.**

And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows.

From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines.

In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment.

I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow.

The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences.

But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings.

A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant.

B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`).

There’s more good news here! Both of these problems are really easy to fix.

To fix (A), someone just has to write the tutorial.

To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH.

I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly.

Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :)

So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)?

I’m looking forward to hearing your thoughts.

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

2016-09-13 21:07 GMT+02:00 Theodore Lief Gannon :

Stack *does* allow direct interaction with GHC:

stack exec -- ghc version

Granted this lacks a bit in brevity, but if you want to issue multiple commands from "inside" stack's private environment, you can also just do this:

stack exec sh

Another option is setting up simple 2-liners like #!/bin/sh stack --resolver=lts-6.17 exec ghc -- "$@" and put them under some sensible name (e.g. ghc-7.10.3) into one's ~/bin, same for ghci. This way you can still keep things nicely separated and in a known state, but still have access to several versions without typing overhead. There are still a few tiny annoying things, though: * There's the "Run from outside a project blah blah" line, and I don't see a way to disable that. This is only a cosmetic issue, but still... * On Windows under a MinGW bash you get a a warning for ghci: $ stack --resolver=nightly-2016-07-01 exec ghci -- --version Run from outside a project, using implicit global project config WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead The Glorious Glasgow Haskell Compilation System, version 8.0.1 But using ghcii.sh through stack doesn't work: $ stack --resolver=nightly-2016-07-01 exec ghcii.sh -- --version Run from outside a project, using implicit global project config D:\Benutzer\Sven\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\bin\ghcii.sh: createProcess: invalid argument (Exec format error) * I've seen variations of "Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d...", too, and I don't have a clue what stack is trying to tell me, either. The message should either be suppressed or improved. As it is, it's useless for the end-user. * From time to time I'd like to remove old stuff which has been installed by stack, e.g. "everything not belonging to the latest LTS" or "everything from nightly-2016-07-01". I can easily blow away the whole ~/.stack directory and re-download/compile only the new stuff I need, but there must be a better way, I hope. This kind of housekeeping is really necessary when you play around a bit with various versions (resulting in tons of GB in ~/.stack) and your relatively small laptop HDD is getting a bit full In a nutshell: I'm quite happy with stack, but it still needs some polishing. When this is done, it can probably make both the "ad hoc" camp and the "multi-GHC-version project/library writer" camp happy.

2016-09-13 21:14 GMT+02:00 John Wiegley :

...

...

...

...

...

"RE" == Richard Eisenberg writes:

RE> To fix (B), stack just needs a new option so that `stack setup` installs a RE> system GHC. Perhaps it would even be sufficient for `stack setup` to RE> clearly tell the user where ghc is installed and what to add to their RE> PATH.

Some other tools provide an "env" sub-command, so that a person can run:

eval $(stack env)

And now ghc, ghci, etc., would be on the PATH, and the user doesn't really need to care about where it lives.

+1

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Alberto.

Thanks, many, for explaining better ways to interact directly with GHC after using a `stack setup`. Perhaps, then, all that’s stopping someone like me from liking the ease of `stack setup` is a little missing PR (as in, public relations). I understand that many people want to keep GHC cloistered away to ease version swapping, but others (like me) want GHC available front and center. Other minor points: `stack env` does not work for me: my version of stack does not know how to `env`. I have version 1.1.2, as installed by `brew install haskell-stack`. Regardless, there are a variety of ways of establishing the right PATH. There was not, to my knowledge, any prior stack gubbins around. This is a new computer I’m working on, and I’m pretty sure this was my first attempt. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

On Sep 13, 2016, at 3:26 PM, Chris Smith wrote:

At this point (and quite sadly) the question is not mainly a technical one. We have difficult decisions to make collectively, by our actions, about whether it's okay to just overlook a years-long campaign of bitter character assassination aimed at core members of the community. For this reason, I think holding some kind of race, and implying that we all ought to just get behind whoever releases a minor UI tweak first, is more likely to hurt than help.

On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg mailto:rae@cs.brynmawr.edu> wrote: I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it.

My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it.

My approach:

1. `brew install haskell-stack`. Success.

At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to

2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including

...

Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc Right Nothing

At the end, I am helpfully told

...

To use this GHC and packages outside of a project, consider using: stack ghc, stack ghci, stack runghc, or stack exec

So I then

3. `stack ghci`. My computer’s first reaction is to say

...

Run from outside a project, using implicit global project config Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml Error parsing targets: The specified targets matched no packages. Perhaps you need to run 'stack init'? Warning: build failed, but optimistically launching GHCi anyway

which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected.

Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I

4. `stack ghc --version`. This command reports

...

Invalid option `--version’

Grumble. It seems I can’t interact with GHC directly.

————

At this point, I am reminded why I dislike stack:

**It’s optimized for a different workflow than I use.**

And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows.

From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines.

In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment.

I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow.

The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences.

But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings.

A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant.

B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`).

There’s more good news here! Both of these problems are really easy to fix.

To fix (A), someone just has to write the tutorial.

To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH.

I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly.

Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :)

So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)?

I’m looking forward to hearing your thoughts.

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae http://cs.brynmawr.edu/~rae

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I almost never (maybe twice in the last year) do this, but when I need an environment that has Stack provided GHC-stuff in the path, I use `stack exec my-shell`. On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery wrote:

On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg wrote:

...

Other minor points: `stack env` does not work for me: my version of stack does not know how to `env`

I think they said that was an add-in. IIRC stack is extensible with external commands, in roughly the same way git is.

(I am also not fond of stack, and even less fond of the politics that go with it, but will stick to the technical here.)

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com

Excerpts from Harendra Kumar's message of 2016-09-14 04:19:39 +0530:

3) But I prefer to just use "export PATH=$(stack path --bin-path)" instead which only sets the PATH. The full environment (when using env or bash) also includes GHC_PACKAGE_PATH which cabal does not like.

See https://github.com/haskell/cabal/issues/3728 Edward

On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg wrote:

Thanks, many, for explaining better ways to interact directly with GHC after using a `stack setup`. Perhaps, then, all that’s stopping someone like me from liking the ease of `stack setup` is a little missing PR (as in, public relations). I understand that many people want to keep GHC cloistered away to ease version swapping, but others (like me) want GHC available front and center.

Other minor points: `stack env` does not work for me: my version of stack does not know how to `env`.

That's correct—stack env was a feature request. The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug (probably because it's a new install)? I use stack (and have contributed a bit recently), but I agree there's a few things stack could do better for this workflow. And the transition has a rather annoying learning curve—stack ghci and stack ghc are not the same as ghci/ghc. I think that's on purpose to support a project-based workflow, and it has upsides, but it's a transition pitfall. Lots of things *are* explained in https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few things from scratch. You want stack exec ghc and stack exec ghci, and arbitrary options require a double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc --version`. And I'm afraid the command syntax is mostly frozen by now. To support a compiler-based workflow, there are a few things planned—I opened an issue to collect them, starting from Simon Marlow's recent email: https://github.com/commercialhaskell/stack/issues/2546 BTW, a system-installed GHC already works if you stick to one (and only build projects that need that). But I'd love to support multiple system-installed GHCs and being able to pick the one you need. As others already explained, giving access to stack-installed GHCs can be problematic—they're going to work, in part, exactly because you can't install in their package database. Having stack install system-wide GHCs would IMHO risk opening a can of worms—having working binaries for all Linux distros requires some work, system installers would be harder and most users would dislike them.

On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen wrote:

Stack users are moving away from enabling system installed GHCs by default because it breaks the ease of enabling profiling for libraries when you're using a Stack-installed GHC.

I'm not sure why multiple system-installed GHCs needs to be supported in addition to the GHC support Stack already provides. That's extra work for...what? Stack isn't trying to compete with Nix. It's more like a blend of rustup and cargo -- or Clojure's Leiningen.

To clarify: I'm not proposing stack to install those GHCs, just to use them. I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC) and has other technical advantages (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm willing to contribute the work and not asking anybody—I've just been busy. Right now I have to modify the PATH every time I use GHC 7.8.4 because I needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by default.

On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso javascript:> wrote:

...

On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg

...

...

Thanks, many, for explaining better ways to interact directly with GHC after using a `stack setup`. Perhaps, then, all that’s stopping someone

...

...

me from liking the ease of `stack setup` is a little missing PR (as in, public relations). I understand that many people want to keep GHC cloistered away to ease version swapping, but others (like me) want GHC available front and center.

Other minor points: `stack env` does not work for me: my version of stack does not know how to `env`.

That's correct—stack env was a feature request.

The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug (probably because it's a new install)?

I use stack (and have contributed a bit recently), but I agree there's a few things stack could do better for this workflow.

And the transition has a rather annoying learning curve—stack ghci and stack ghc are not the same as ghci/ghc. I think that's on purpose to support a project-based workflow, and it has upsides, but it's a transition

wrote: like pitfall.

...

Lots of things *are* explained in https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few things from scratch.

You want stack exec ghc and stack exec ghci, and arbitrary options require a double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc --version`. And I'm afraid the command syntax is mostly frozen by now.

To support a compiler-based workflow, there are a few things planned—I opened an issue to collect them, starting from Simon Marlow's recent email: https://github.com/commercialhaskell/stack/issues/2546

BTW, a system-installed GHC already works if you stick to one (and only build projects that need that). But I'd love to support multiple system-installed GHCs and being able to pick the one you need.

As others already explained, giving access to stack-installed GHCs can be problematic—they're going to work, in part, exactly because you can't install in their package database.

Having stack install system-wide GHCs would IMHO risk opening a can of worms—having working binaries for all Linux distros requires some work, system installers would be harder and most users would dislike them.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

How would I use stack with a GHC 8.0.2 release candidate? On 13 September 2016 at 21:27, Christopher Allen wrote:

Stack is not your shell, a build script, or a Makefile. It already has path management for the GHC installations it provisions and supports. It is not Stack's job to mutilate your path to support external GHC installations.

Make a Makefile or add shortcuts to your bashrc to switch compilers.

...

On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen wrote:

...

Stack users are moving away from enabling system installed GHCs by default because it breaks the ease of enabling profiling for libraries when you're using a Stack-installed GHC.

...

I'm not sure why multiple system-installed GHCs needs to be supported in addition to the GHC support Stack already provides. That's extra work for...what? Stack isn't trying to compete with Nix. It's more like a blend of rustup and cargo -- or Clojure's Leiningen.

To clarify: I'm not proposing stack to install those GHCs, just to use

On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso wrote: them.

...

I think the extra work would be limited (calling GHC-X.Y.Z instead of

...

and has other technical advantages (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm willing to contribute the work and not asking anybody—I've just been busy.

Right now I have to modify the PATH every time I use GHC 7.8.4 because I needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by default.

...

On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso wrote:

...

On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg wrote:

...

Thanks, many, for explaining better ways to interact directly with

GHC

...

...

...

after using a `stack setup`. Perhaps, then, all that’s stopping someone like me from liking the ease of `stack setup` is a little missing PR (as in, public relations). I understand that many people want to keep GHC cloistered away to ease version swapping, but others (like me) want GHC available front and center.

Other minor points: `stack env` does not work for me: my version of stack does not know how to `env`.

That's correct—stack env was a feature request.

The warning on `stack ghci` doesn't happen usually, but I'd say

...

...

...

bug (probably because it's a new install)?

I use stack (and have contributed a bit recently), but I agree

GHC) that's a there's a

...

...

...

few things stack could do better for this workflow.

And the transition has a rather annoying learning curve—stack ghci and stack ghc are not the same as ghci/ghc. I think that's on purpose to support a project-based workflow, and it has upsides, but it's a transition pitfall. Lots of things *are* explained in https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few things from scratch.

You want stack exec ghc and stack exec ghci, and arbitrary options require a double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc --version`. And I'm afraid the command syntax is mostly frozen by now.

To support a compiler-based workflow, there are a few things planned—I opened an issue to collect them, starting from Simon Marlow's recent email: https://github.com/commercialhaskell/stack/issues/2546

BTW, a system-installed GHC already works if you stick to one (and only build projects that need that). But I'd love to support multiple system-installed GHCs and being able to pick the one you need.

As others already explained, giving access to stack-installed GHCs can be problematic—they're going to work, in part, exactly because you can't install in their package database.

Having stack install system-wide GHCs would IMHO risk opening a can of worms—having working binaries for all Linux distros requires some work, system installers would be harder and most users would dislike them.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

But what if I don't want to fiddle with my PATH? Why is it so bad for stack to have a --with-ghc option to tell it what GHC to use? On 14 September 2016 at 16:23, Christopher Allen wrote:

Probably pretty similarly to how we use patched GHCJS at work with Stack.

-- from the stack.yaml system-ghc: true compiler: ghcjs-0.2.0_ghc-7.10.2 resolver: ghcjs-0.2.0_ghc-7.10.2

-- in the Makefile ghcjs: git clone https://github.com/myorg/ghcjs cd ghcjs && stack setup && stack install cd ghcjs && stack install cabal-install alex happy cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock

It's just picking GHCJS up from the path, with system-ghc: true, we're telling it that is kosher.

We disable system-ghc usage for regular GHC projects, it makes profiling less convenient than if you use a Stack managed GHC but if you're doing GHC dev the difference means nothing.

...

How would I use stack with a GHC 8.0.2 release candidate?

On 13 September 2016 at 21:27, Christopher Allen wrote:

...

Stack is not your shell, a build script, or a Makefile. It already has path management for the GHC installations it provisions and supports. It is not Stack's job to mutilate your path to support external GHC installations.

Make a Makefile or add shortcuts to your bashrc to switch compilers.

On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso

...

wrote:

...

On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen wrote:

...

Stack users are moving away from enabling system installed GHCs by default because it breaks the ease of enabling profiling for

...

...

...

...

when you're using a Stack-installed GHC.

...

I'm not sure why multiple system-installed GHCs needs to be supported in addition to the GHC support Stack already provides. That's extra work for...what? Stack isn't trying to compete with Nix. It's more like a blend of rustup and cargo -- or Clojure's Leiningen.

To clarify: I'm not proposing stack to install those GHCs, just to use them.

I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC) and has other technical advantages (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm willing to contribute the work and not asking anybody—I've just been busy.

Right now I have to modify the PATH every time I use GHC 7.8.4 because I needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by default.

...

On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso

...

...

...

wrote:

...

On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard

Eisenberg

...

wrote: > > Thanks, many, for explaining better ways to interact directly with > GHC > after using a `stack setup`. Perhaps, then, all that’s stopping > someone > like > me from liking the ease of `stack setup` is a little missing PR (as > in, > public relations). I understand that many people want to keep GHC > cloistered > away to ease version swapping, but others (like me) want GHC > available > front > and center. > > Other minor points: > `stack env` does not work for me: my version of stack does not know > how > to > `env`.

That's correct—stack env was a feature request.

The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug (probably because it's a new install)?

I use stack (and have contributed a bit recently), but I agree there's a few things stack could do better for this workflow.

And the transition has a rather annoying learning curve—stack ghci and stack ghc are not the same as ghci/ghc. I think that's on purpose to support a project-based workflow, and it has upsides, but it's a transition pitfall. Lots of things *are* explained in https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few things from scratch.

You want stack exec ghc and stack exec ghci, and arbitrary options require a double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc --version`. And I'm afraid the command syntax is mostly frozen by now.

To support a compiler-based workflow, there are a few things planned—I opened an issue to collect them, starting from Simon Marlow's recent email: https://github.com/commercialhaskell/stack/issues/2546

BTW, a system-installed GHC already works if you stick to one (and only build projects that need that). But I'd love to support multiple system-installed GHCs and being able to pick the one you need.

As others already explained, giving access to stack-installed GHCs can be problematic—they're going to work, in part, exactly because you can't install in their package database.

Having stack install system-wide GHCs would IMHO risk opening a can of worms—having working binaries for all Linux distros requires some work, system installers would be harder and most users would dislike

On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow wrote: libraries them.

...

...

...

...

...

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- Chris Allen Currently working on http://haskellbook.com

While we're griping about stack: it seems to place compiler output from -ddump-... in mysterious places that are hard to find without Google, and (worse) it seems to do something with stack test output that even Google can't discover. On Sep 14, 2016 11:59 AM, "Michael Snoyman" wrote:

I don't think anyone thinks it's bad to have a --with-ghc option, AFAIK the only reason it hasn't been done is lack of desire/time, since it's an uncommon workflow. Unlike with cabal, the normal way to specify a different GHC is with the `--resolver` setting. AFAIK, this flag could be added.

On Wed, Sep 14, 2016 at 6:54 PM, Simon Marlow wrote:

...

But what if I don't want to fiddle with my PATH? Why is it so bad for stack to have a --with-ghc option to tell it what GHC to use?

On 14 September 2016 at 16:23, Christopher Allen wrote:

...

Probably pretty similarly to how we use patched GHCJS at work with Stack.

-- from the stack.yaml system-ghc: true compiler: ghcjs-0.2.0_ghc-7.10.2 resolver: ghcjs-0.2.0_ghc-7.10.2

-- in the Makefile ghcjs: git clone https://github.com/myorg/ghcjs cd ghcjs && stack setup && stack install cd ghcjs && stack install cabal-install alex happy cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock

It's just picking GHCJS up from the path, with system-ghc: true, we're telling it that is kosher.

We disable system-ghc usage for regular GHC projects, it makes profiling less convenient than if you use a Stack managed GHC but if you're doing GHC dev the difference means nothing.

...

How would I use stack with a GHC 8.0.2 release candidate?

On 13 September 2016 at 21:27, Christopher Allen wrote:

...

Stack is not your shell, a build script, or a Makefile. It already has path management for the GHC installations it provisions and supports. It is not Stack's job to mutilate your path to support external GHC installations.

Make a Makefile or add shortcuts to your bashrc to switch compilers.

On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso <

...

...

wrote:

...

On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen wrote: > > Stack users are moving away from enabling system installed GHCs by > default because it breaks the ease of enabling profiling for

...

...

...

> when you're using a Stack-installed GHC.

> > I'm not sure why multiple system-installed GHCs needs to be supported > in addition to the GHC support Stack already provides. That's extra > work for...what? Stack isn't trying to compete with Nix. It's more > like a blend of rustup and cargo -- or Clojure's Leiningen.

To clarify: I'm not proposing stack to install those GHCs, just to use them.

I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC) and has other technical advantages (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm willing to contribute the work and not asking anybody—I've just been busy.

Right now I have to modify the PATH every time I use GHC 7.8.4 because I needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by default.

> > On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso <

...

...

...

> wrote: > > > > > > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg > > wrote: > >> > >> Thanks, many, for explaining better ways to interact directly with > >> GHC > >> after using a `stack setup`. Perhaps, then, all that’s stopping > >> someone > >> like > >> me from liking the ease of `stack setup` is a little missing PR (as > >> in, > >> public relations). I understand that many people want to keep GHC > >> cloistered > >> away to ease version swapping, but others (like me) want GHC > >> available > >> front > >> and center. > >> > >> Other minor points: > >> `stack env` does not work for me: my version of stack does not know > >> how > >> to > >> `env`. > > > > > > That's correct—stack env was a feature request. > > > > The warning on `stack ghci` doesn't happen usually, but I'd say > > that's a > > bug > > (probably because it's a new install)? > > > > I use stack (and have contributed a bit recently), but I agree > > there's a > > few > > things stack could do better for this workflow. > > > > And the transition has a rather annoying learning curve—stack ghci > > and > > stack > > ghc are not the same as ghci/ghc. I think that's on purpose to > > support a > > project-based workflow, and it has upsides, but it's a transition > > pitfall. > > Lots of things *are* explained in > > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a > > few > > things from scratch. > > > > You want stack exec ghc and stack exec ghci, and arbitrary

...

...

...

> > require a > > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc > > --version`. And I'm afraid the command syntax is mostly frozen by > > now. > > > > To support a compiler-based workflow, there are a few things > > planned—I > > opened an issue to collect them, starting from Simon Marlow's recent > > email: > > https://github.com/commercialhaskell/stack/issues/2546 > > > > BTW, a system-installed GHC already works if you stick to one (and > > only > > build projects that need that). But I'd love to support multiple > > system-installed GHCs and being able to pick the one you need. > > > > As others already explained, giving access to stack-installed GHCs > > can > > be > > problematic—they're going to work, in part, exactly because you can't > > install in their package database. > > > > Having stack install system-wide GHCs would IMHO risk opening a can > > of > > worms—having working binaries for all Linux distros requires some > > work, > > system installers would be harder and most users would dislike

On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow wrote: p.giarrusso@gmail.com> libraries p.gia...@gmail.com> options them.

...

...

...

> > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- Chris Allen Currently working on http://haskellbook.com

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

What are you talking about? $ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... On Wed, Sep 14, 2016 at 2:10 PM, Patrick Pelletier wrote:

On 9/14/16 10:47 AM, David Feuer wrote:

...

While we're griping about stack: it seems to place compiler output from -ddump-... in mysterious places that are hard to find without Google, and (worse) it seems to do something with stack test output that even Google can't discover.

Also, compiler warnings get squirreled away in a file that I have to go hunting for. It would be nice to have an option to print warnings (for local packages, not dependencies) to stderr.

--Patrick

_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- Chris Allen Currently working on http://haskellbook.com

On 9/14/16 12:21 PM, Christopher Allen wrote:

What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me: whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o ) Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool() Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o ) Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in /Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$ I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage. --Patrick

That's good news. I think the community will benefit from a healthy competition among the tools. It is good to have choices in terms of the front end but I would rather prefer a unified specification of configuration. Currently with a stack workflow one has to deal with two config files i.e. stack.yaml and project.cabal. There is no reason why the stack and cabal configs cannot be unified. The concept of frozen snapshots is generic and useful enough to be incorporated as a common specification used by all tools. If there is a unified config then the same package can be used with stack or cabal, with hackage or stackage without any problems, choose what you prefer. Another point that I want to make is that I have found the cabal config files hard to deal with. There are a number of annoying problems with it and it lacks in reuse. That is the reason for tools like hpack ( https://github.com/sol/hpack) to be built to overcome those problems. I think the problems that hpack solves should be natively solved by cabal. I guess these problems are long pending and cabal did not evolve fast enough. That could be one of the reasons for wrappers on top of cabal or competing tools like stack getting created. Are there any thoughts going towards a better config specification? While we are at it it maybe good to have an extensible config which can provide optional tool specific extensions. -harendra On 15 September 2016 at 06:12, Duncan Coutts via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

On Tue, 2016-09-13 at 14:58 -0400, Richard Eisenberg wrote:

...

I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

Since this is all being discussed now, it is perhaps worth explaining what the cabal developers are working on and the direction they're going.

The cabal tool is getting a major overhaul. At this point there's a relatively large group of people who have been "dogfooding" it in their normal daily work for months (and for a few brave users since the beginning of the year).

There is a tech preview of this in the 1.24 release. The latest git version has a user guide which explains things in more detail, and what you can expect to work already and what is known to be incomplete (including several temporary workarounds for missing features).

https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html

What is broadly the same is that it still supports the "library solver- based, work with my current ghc / environment" style that people have mentioned in this thread. For example by default it picks up the ghc on your path (and will automagically do the right thing if you change your path).

That said, the intention is also to better support a "application frozen / package collection" style, which is the style that stack supports well currently.

What is new is that it does what it does a whole lot better, more conveniently, more predictably. There's a lot fewer cases where you have to use multiple commands to do various steps. Much of the time you can simply ask to build/repl something, and everything else is automatic (and quick to not do much if not much changed). It's more predictable in that it's much more deterministic. The choices about what versions etc are picked depend only on your environment (e.g. ghc version), hackage snapshot and local explicit project state. In particular it does not matter what you installed previously. (To support the application/frozen workflows these aspects of the environment can all be captured and frozen in a project file.)

It also avoids the "cabal hell" issues of clashing installed versions. Or to put it another way, it's a bit like sandboxing but without the mental overhead or the waiting around for everything to build (because there's automatic maximal sharing of built packages, a la nix).

It *is* project based, but a minimal project can actually be implicit, and most projects don't need to specify anything more than a list (or glob) of the directories of the packages in the project.

One of the things you were mentioning was how nice it is to just be able to run ghc or ghci on a source file, or even without any file, just to play around. A feature that will be landing soon in cabal- install head is the ability to simply run ghc/ghci within a cabal project directory and ghc will start up in the environment of the project. No extra wrapper scripts, shell sessions or env vars necessary.

So the short term goal is to get all this to the stage where it can replace the default UI in the cabal tool, and thereafter one goal is to better support the workflow style that stack currently supports well, ie applications with frozen / carefully change-controlled environment, and package collections/snapshots chosen by 3rd parties.

I should also say that any help is most welcome. Development takes place on github. We now have several active reviewers so review & feedback on contributions is very quick. It's not all just hard problems, there's plenty to do for newcommers too (e.g. write that tutorial!). There's an active #hackage IRC channel. Newcommers are always welcome.

Duncan _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

While I agree that stack.yaml is a frozen config, we do not necessarily need a separate config file or a separate format for that. My main point was a that a new user will have to understand two more languages (YAML/cabal) in addition to Haskell. We can have the config spread in multiple files, but they should look like an extension of the same thing rather than disparate things. The stack snapshot config can be seen as a higher level concept of the pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the snapshot is a point in that space. It can also be seen as a more general version of the "tested-with" field in the cabal file. We can instead say - tested-with these snapshots (or set of versions). Instead of using stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list which snapshot configs that are available and you can choose which one you want to build. The config could be tool agnostic. -harendra On 15 September 2016 at 11:36, Patrick Pelletier wrote:

On 9/14/16 7:46 PM, Harendra Kumar wrote:

...

That's good news. I think the community will benefit from a healthy competition among the tools. It is good to have choices in terms of the front end but I would rather prefer a unified specification of configuration. Currently with a stack workflow one has to deal with two config files i.e. stack.yaml and project.cabal. There is no reason why the stack and cabal configs cannot be unified.

To me, the stack.yaml and project.cabal file serve different purposes. The project.cabal specifies how to build a single package. Even if you want to (try to) build that library in a very different build environment, everything in the project.cabal is still meaningful: source files, dependencies, license, how to run tests and benchmarks, etc.

The stack.yaml is about an entire build environment. It is about things that have to (of necessity) be the same for all the packages that go into an executable: compiler version, snapshot, etc.

In other words, a single build environment can build many packages, and a single package can be built in many different environments. For example, in my directory structure for developing normalization-insensitive, I have three stack.yaml files:

stack-7.8.yaml stack-7.10.yaml stack-8.0.yaml

and I have three cabal files:

unicode-transforms/unicode-transforms.cabal normalization-insensitive/normalization-insensitive.cabal photos/photos.cabal

Each stack.yaml builds all three cabal projects. And each cabal project can be built by any of the three stack.yaml files. So, I see them as expressing very different concepts.

Another point that I want to make is that I have found the cabal config

...

files hard to deal with. There are a number of annoying problems with it and it lacks in reuse. That is the reason for tools like hpack ( https://github.com/sol/hpack) to be built to overcome those problems. I think the problems that hpack solves should be natively solved by cabal.

Yes, it would be nice if cabal-the-library could learn from hpack and solve some of the problems like redundancy. I just wouldn't want to see fragmentation of the Haskell ecosystem. (In other words, I want to be able to easily use any Haskell library as a dependency, even if the tools I am using are different than the tools the package author used.)

I guess these problems are long pending and cabal did not evolve fast

...

enough. That could be one of the reasons for wrappers on top of cabal or competing tools like stack getting created.

Well, hpack is addressing issues with the file format used by cabal-the-library, while stack is addressing issues with cabal-install-the-program.

Are there any thoughts going towards a better config specification? While

...

we are at it it maybe good to have an extensible config which can provide optional tool specific extensions.

Yes, that would be very nice.

--Patrick

On 15 September 2016 at 19:53, Edward Z. Yang wrote:

Well, if the "snapshot" config is put in specific file, there's no reason why Cabal couldn't be taught to also read configuration from that file. But if cabal-install wants it to be in "pkg description format" and Stack wants it to be in YAML I'm not sure how you are going to get the projects to agree on a shared format. Snapshot config is put in cabal.project.freeze, which has the virtue of having the *same* format of cabal.project.

How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format? In the short run it is tempting to keep using .cabal since we do not have to manage a painful disruptive change. But that may not be so in the long run. Open technologies usually win in the long run as against the closed ones. Keeping aside the legacy knowledge advantage, we can objectively evaluate if .cabal is better than YAML or vice versa. Inputs from original stack authors might also be useful on why they chose YAML over .cabal. I guess it might be similar to the reasons why someone wrote hpack to generate .cabal from YAML. Also they were starting fresh and so did not have to manage a disruptive change. But I fear if they will be willing to go for a closed format against an open format now even if some of the problems of the format are addressed. Maintaining a closed format perennially is also an issue unless it is very well thought out and does not require any changes. -harendra

On 16 September 2016 at 04:54, Brandon Allbery wrote:

On Thu, Sep 15, 2016 at 7:19 PM, Harendra Kumar wrote:

...

How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format?

Could you explain what aspect of a format for which all code and documentation is open source defines it as "closed" to you?

Well, I did not mean closed in that sense. What I meant was it is custom built for a very specific purpose, maybe I chose the wrong word, sorry about that. -harendra

How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format?

I understand YAML is a very popular format, but it is not all roses. It's an extremely complicated format (http://yaml.org/spec/1.2/spec.html). Cabal's lexical format is very simple, because it doesn't really need to support much (the rest is deferred to sub-parsers on fields.) In some since, YAML is overkill for Stack, which actually doesn't use very many of its features (https://docs.haskellstack.org/en/stable/yaml_configuration/) If I were designing a package ecosystem from scratch, I'm not sure what format I would pick. Take Rust Cargo; they didn't use YAML, they used TOML (https://github.com/toml-lang/toml) in no small part due to the fact that YAML is complicated. I'd want the output to be associated with locations so I could give error messages that refer to the input file; no one does that today...

Inputs from original stack authors might also be useful on why they chose YAML over .cabal. I guess it might be similar to the reasons why someone wrote hpack to generate .cabal from YAML. Also they were starting fresh and so did not have to manage a disruptive change. But I fear if they will be willing to go for a closed format against an open format now even if some of the problems of the format are addressed. Maintaining a closed format perennially is also an issue unless it is very well thought out and does not require any changes.

I suspect the reason is much more banal: Cabal's parser implementation is pretty byzantine and difficult to use. So rather than fight something like that, just use something will a nicer API. Edward

On 2016-09-16 02:19, Christopher Allen wrote:

The YAML parser backing hpack and Stack supports a subset of yaml, so the complexity isn't there.

As I understand it, the point of using YAML in this case isn't that "there's a library for that". It's that it's *standard* such that other tools can read/write it and know for certain that what gets read/written is at the very least 'syntactically' correct. As such, using some nebulous "subset of yaml" defined by an implementation[1] doesn't really make sense for interop purposes. (I'm honestly not sure how many *actually* fully conforming YAML parsers there are out there, but I'd place my bets of "not many" given the complexity of the spec. See http://yaml.org/spec/1.2/spec.html )

TOML isn't supported because a well-supported/known-good library wasn't to hand, whereas the yaml one did. I don't think people would mind changing over, but somebody has to do the work validating that the one-still-maintained-of-two-libraries TOML library is suitable.

Even though there are probably fewer implementations, TOML is aiming[2] to become a standard format, so it's (hopefully going to be) a standard and a much simpler one than YAML. That'll hopefully lead to more implementations over time, but who knows? It's *also* simple enough that implementing a fully conforming parser/writer is probably a few days' work, if that. That means that any tools that cannot use an existing library (for whatever reason) actually have a shot in hell of implementing TOML support themselves. That is not the case for YAML -- witnessed by the number of yaml libaries that are actually just bindings for C-based yaml libraries. (I have other issues with TOML, but that's a different matter. The major sticking point for me would be the lack of *clean* support for nesting without the order-dependence, but that may not matter much for Cabal.)

Keep in mind while discussing all this that Cabal's own solver doesn't actually live outside of cabal-install.

FWIW, this seems mostly like a historical accident more than anything else and at this point it's a *very* non-trivial undertaking to fully separate it out, though there have been steps in this direction. I don't see it happening unless the parties who are actually interested in *using* it outside of cabal-install do the majority of the work.

Contributing to the Cabal project itself is a gauntlet run, which is partly why many of these projects spawned outside of it. Further, Cabal itself can't really grow any dependencies because of the bootstrap problem.

Nobody wants to shim / inline all the dependencies that enable the devs to work efficiently into Cabal and such a PR would never get merged anyway.

You're right that Cabal-the-library is generally a very difficult thing to change (due to sheer inertia and stability guarantees), but -- as Patrick Pelletier points out -- implementing a new file format shouldn't matter for consumers of Cabal as long as Cabal emits the old standard Cabal configuration data structures. Meanwhile, it would open up the possibility of non-Cabal-based programs understanding and writing .cabal files (up to semantics defined by documentation). I'm not sure how much that benefit that would confer, but given that Cabal's parser is already a mess[3] with loads of corner cases I'd say it's probably worth it *just* from a software engineering perspective to get the basic syntax parsing disconnected from Cabal and to get rid of the old code. Btw, Cabal/cabal-install development has opened up and picked up pace considerably in the last year or two, you might want to reconsider automatically concluding that such-and-such PR "[...] would never get merged anyway". Anyway, this sub-thread is probably veering too off-topic, so I'll stop there. Regards, /b Notes: [1] At least, from a quick skim of the available documentation at https://hackage.haskell.org/package/yaml I wasn't able deduce what subset of YAML was supposed to be supported. Maybe I just missed it. [2] As of now the README for the current v0.4.0 spec says: "Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly.". I guess one can pin to 0.4.0. [3] Work to at least replace it with a parsec-based implementation has been happening here, but the amount of work in https://github.com/haskell/cabal/pull/3602 seems indicative of a *lot* of complexity. (Granted it's hard to tell exactly how much of that complexity is due to mapping to Cabal's data structure vs. just the "parse into a KV-map" bits.)

On Mon, Sep 26, 2016 at 4:23 PM, Richard Eisenberg wrote:

Thanks, Michael, for repeating this here. (I'm not on Twitter, as you may have figured out.)

So, as I understand it, I could use the procedure below to install a "system GHC", which could then be filled out with libraries by either `cabal install xxx` or `stack install xxx`.

If this is indeed the case, I will expect to recommend stack to my students next semester, along with instructions of how to modify their PATHs. I'd also be happy to reconsider recommending stack as the one option on a downloads page, if we include the PATH updating instructions.

This is _almost_ the case. When you use `stack install xxx` (or, for that matter, `cabal install xxx` inside a sandbox), no packages will be registered in the default user package database. Without modifying `GHC_PACKAGE_PATH`, those packages will not be available from a straight `runghc`. By contrast, `stack exec -- runghc` _will_ have access because it sets the `GHC_PACKAGE_PATH` env var. One possibility to overcome this is to just modify your ~/.bashrc to say: export PATH=$(stack path --bin-path) export GHC_PACKAGE_PATH=$(stack path --ghc-package-path) This is probably a fairly safe move overall, but it's not well tested (or, at least, _I_ haven't tested it well). Then you'd be able to `stack build some-library` and have it available. Or, leave off GHC_PACKAGE_PATH, use a `cabal install some-library` without a sandbox, and get the same result. (Typical downsides of lack of sandboxes would apply of course.)

With regard to `stack exec`: If I modify my PATH to allow direct calls to ghc(i) and then create a project with a stack.yaml, won't `stack exec` use the local settings, etc., when I'm in a subdirectory of the project? At the bottom of your email, it sounds like you're recommending not modifying my PATH, instead always using `stack exec` for a better experience. But it seems to me that modifying my path allows me to skip the `stack exec` outside of projects while still retaining the nice behavior inside of projects, a net win to my eyes. (Your opinion on this may differ, of course.) Is there something I'm missing here?

It's really a matter of what you consider best, thus my referral to established workflows. If you use the PATH modification trick, and have a global configuration targeting GHC 8.0.1, and then go inside a directory that using GHC 7.10.3: * `stack exec -- ghc` will use GHC 7.10.3 * `ghc` will use GHC 8.0.1 Honestly, this somewhat gets to a point of trying to read the user's mind about what the anticipated behavior is. Personally, I've come to expect and enjoy the behavior of respecting the local settings, though there are certainly times when it's _not_ what I want. So take my recommendation to stick with `stack exec --` with a large grain of salt; as long as you understand that `stack exec ghc` and `ghc` in a given directory may behave differently, the PATH trick can work. And especially for teaching purposes, I can imagine the situation of multiple GHC versions to be a much smaller concern.

(Sidenote: You used `stack build` where I expected `stack install` in your gist. I understand that the latter copies executables somewhere and the former does not, but then it seems that the binaries are available in `stack path --bin-path`, so I'm a bit confused.)

Every project has a .stack-work directory, and (somewhere) inside of that is a /bin/ directory, where `stack build` automatically copies executables to. (A similar directory exists for each snapshot.) When you use `stack exec`, it adds these /bin/ directories to your PATH, so that you can easily run locally built executables. This is useful in many cases, but perhaps the most important is when you have an executable (like intero or ghc-mod) which is built against a specific GHC version: you're guaranteed to get the appropriate binary instead of whatever the last one to be installed happens to be. `stack install` by contrast copies this binaries out of those /bin/ directories and into ~/.local/bin (and somewhere else on Windows, I don't remember where offhand). This is a semi-standard directory for installing user built tools. This makes a lot of sense for tools like pandoc, stylish-haskell, hindent, etc: tools you'd want to use regardless of GHC version, and possibly when not working on Haskell code at all.

Thanks again for your input here! Richard

Pleasure, thanks for starting the conversation :) Michael

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

On Sep 26, 2016, at 6:32 AM, Michael Snoyman wrote:

I just realized that I had shared this answer on Twitter, but not on this mailing list.

For those wanting to have direct access to GHC and other such tools, without needing to prefix calls with `stack exec -- `, the following added to your ~/.bashrc (or equivalent) will do the trick:

export PATH=`stack path --bin-path`

This can go as far as providing a means of using cabal-install, for example:

https://gist.github.com/snoyberg/959a2ade4287de6129910eeabec1d9d2

For those without an established workflow, or open to experimenting with new workflows, I'd still recommend sticking with `stack exec -- ` in general, since it composes nicely with projects, letting you automatically switch to different GHC versions and package sets. But this is certainly another option to consider.

On Tue, Sep 13, 2016 at 9:58 PM, Richard Eisenberg wrote:

...

I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it.

My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it.

My approach:

1. `brew install haskell-stack`. Success.

At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to

2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including

...

Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc Right Nothing

At the end, I am helpfully told

...

To use this GHC and packages outside of a project, consider using: stack ghc, stack ghci, stack runghc, or stack exec

So I then

3. `stack ghci`. My computer’s first reaction is to say

...

Run from outside a project, using implicit global project config Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml Error parsing targets: The specified targets matched no packages. Perhaps you need to run 'stack init'? Warning: build failed, but optimistically launching GHCi anyway

which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected.

Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I

4. `stack ghc --version`. This command reports

...

Invalid option `--version’

Grumble. It seems I can’t interact with GHC directly.

————

At this point, I am reminded why I dislike stack:

**It’s optimized for a different workflow than I use.**

And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows.

From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines.

In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment.

I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow.

The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences.

But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings.

A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant.

B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`).

There’s more good news here! Both of these problems are really easy to fix.

To fix (A), someone just has to write the tutorial.

To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH.

I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly.

Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :)

So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)?

I’m looking forward to hearing your thoughts.

Richard

-=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Mon, Sep 26, 2016 at 4:36 PM, Sean Leather wrote:

Hi Michael,

On Mon, Sep 26, 2016 at 12:32 PM, Michael Snoyman wrote:

...

For those wanting to have direct access to GHC and other such tools, without needing to prefix calls with `stack exec -- `, the following added to your ~/.bashrc (or equivalent) will do the trick:

export PATH=`stack path --bin-path`

This is not the side-effect-free function I expected it to be. I just tried it on a Mac after a new install of stack:

$ stack path --bin-path Run from outside a project, using implicit global project config Using resolver: lts-7.0 from implicit global project's config file: ~/.stack/global-project/stack.yaml Fetched package index. Populated index cache. No compiler found, expected minor version match with ghc-8.0.1 (x86_64) (based on resolver setting in /Users/leather/.stack/global- project/stack.yaml). Try running "stack setup" to install the correct GHC into ~/.stack/programs/x86_64-osx/

The above took nearly 10 minutes and failed. I would not recommend doing that in a ~/.bashrc.

See https://github.com/commercialhaskell/stack/issues/2325 for the issue I reported in July.

Regards, Sean

That's a fair point, but if the user first runs `stack setup` (which I'd recommend in any usage of this line), it does become side-effect-free. Regarding #2325: it might make sense to have `stack path` simply fail if no project file is found, but user intent is a bit unclear on that point. Michael