Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Phil Ruffwind]

On Tue, Sep 13, 2016, at 16:24, Sven Panne wrote:
>
>* 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)

My guess is that `stack.exe` executes commands using the native Windows
`CreateProcess`, which has no concept of Bash-like shell scripts (since
they are a foreign thing introduced by MinGW).  Perhaps try something
like `stack exec sh ghcii.sh` instead?  (Or `stack exec -- sh -c
` if you want to be agnostic to whether `` is a true
executable or just a script.)
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Michael Snoyman]

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Michael Snoyman]

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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Sean Leather]

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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Richard Eisenberg]

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.

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?

(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.)

Thanks again for your input here!
Richard

-=-=-=-=-=-=-=-=-=-=-
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 com

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Michael Snoyman]

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 

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Edward Z. Yang]

On September 16, 2016 9:19:16 AM GMT+09:00, Christopher Allen 
 wrote:
>The YAML parser backing hpack and Stack supports a subset of yaml, so
>the complexity isn't there.

Is the subset of yaml that Stack supports deacribed anywhere? The yaml package 
(which Stack depends on) seems to suggest it supports a pretty beefy chunk of 
YAML, e.g. including includes.

>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.

I'm not suggesting you change over. My feeling is that once a choice like this 
is made, it is very hard to change post facto. Need to build infrastructure for 
migrating to new format if you do.

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

Here is the ticket tracking the issue:
https://github.com/haskell/cabal/issues/3781

Basically, everyone agrees it should happen, but there is a bit of work that 
has to be done, esp. API design, and most of us have other issues we are frying.

> Contributing to the Cabal
>project itself is a gauntlet run, which is partly why many of these
>projects spawned outside of it.

I know that this was true in the past, and it is hard to regain trust and 
reputation. But I think things are better now. Our turnaround time for new PRs 
is now much quicker, and if you submit a PR we will give you commit bits. 
Obviously that doesn't make up for any past failings, but please give us 
another look!

> Further, Cabal itself can't really
>grow any dependencies because of the bootstrap problem.

I don't think this is inherently unsolvable. Just work. It would be reasonable 
to remove Cabal from boot packages GHC distributes and require 
cabal-install/Stack to bootstrap a sufficiently new version of Cabal library. 
But you would have to do work to make sure that you dont end up building half 
the universe on a fresh GHC build. GHC devs would not like that.

>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.

Out of curiosity, what are the libraries that are most painful to not have 
available from the boot libraries?

Edward

>On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang  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?
>>
>> 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
>> ___
>> Haskell-community mailing list
>> Haskell-community@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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

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.

Keep in mind while discussing all this that Cabal's own solver doesn't
actually live outside of cabal-install. 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.

On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang  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?
>
> 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
> ___
> 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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Edward Z. Yang]

> 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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

On 9/15/16 4: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?


The legacy reasons are important.  Haskell has a wonderfully rich 
software ecosystem, and I wouldn't want to see that ruined by fragmentation.


At the very least, if hpack is going to be supported as an alternative 
to .cabal files, the support should be implemented in cabal-the-library, 
not in the front-ends like cabal-install or stack.  As long as all the 
front-ends use cabal-the-library to parse project files, then 
cabal-the-library can add support for new types of project files (while 
still keeping support for .cabal files) without risk of fragmentation.


--Patrick

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

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?

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Edward Z. Yang]

Excerpts from Harendra Kumar's message of 2016-09-15 13:02:50 +0530:
> 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.

For what it's worth, cabal.project files use the same parser/lexical
structure as Cabal files; the fields/stanzas are just different.  I'm
not familiar with the reasons why Stack decided to use YAML for their
configuration format.

> 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.

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.

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Duncan Coutts via Haskell-community]

On Thu, 2016-09-15 at 08:16 +0530, 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.

As Patrick pointed out, your mypackage.cabal file covers a different
concept to either a stack.yml (or cabal-install's equivalents a
cabal.config or new cabal.project files).

This comes back to the separation of roles between the package author
and the package builder. Sometimes you are both the author and the
builder, but often enough you are building someone else's package, or
someone else is building your package. The person building the package
gets to decide things about the environment that the author does not
either know or choose (though they can describe the constraints on what
range of environments work).

So there has always been this separation between what you can write in
a .cabal file (author role), and what you can say on the command line
when you call cabal, or equivalently what you can write down in a
cabal.config (or new cabal.project) files, or stack's equivalent the
stack.yml file.

>  The concept of frozen snapshots is generic and useful enough to be
> incorporated as a common specification used by all tools.

The concept of package collections like stackage is certainly something
that can have a common spec.

More generally freezing involves keeping track of aspects of the
environment, and this is a bit more fuzzy because it depends how far
you want to go. One can just track versions of Haskell packages or go
as far as nix style package management where all aspects of the input
environment are captured.

> 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.

I don't foresee any particular problems here. They're using the same
.cabal files, and hopefully at some point both will be able to use the
same package collections. I don't think we'll unify the cabal.config
(or new cabal.project) and stack.yml files any time soon since these
deal with the project level builder role (as opposed to package level
author role) and the way the two tools deal with these things is a bit
different (and needs to be different so both tools can innovate).

> 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.

Yes. The plan is to allow "common" sections to be defined and then
included/merged into other sections. At the simplest this would be one
common section that is implicitly merged into all the components (ie
libs, exes etc) but in general would be multiple named sections that
are explicitly included. This change is dependent on a big rewrite of
the .cabal file parser that is underway.

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

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
>
>
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

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

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Duncan Coutts via Haskell-community]

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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

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-c...@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 b

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

Weird. I'd say it's worth raising a bug over whether it's intentional
behavior or not. A package not marked as an extra dep IME reports
warnings and IMO _should_. If you don't have time, tell me and I'll
report it for you.

On Wed, Sep 14, 2016 at 3:20 PM, Patrick Pelletier
 wrote:
> On 9/14/16 1:10 PM, Christopher Allen wrote:
>>
>> I see what is meant now, but it's not really applicable. If I am
>> co-developing a package and its dependencies, I add them as packages
>> (not deps) to my stack.yaml and still get the warnings.
>>
>> Example:
>>
>>  From the stack.yaml for the package that uses my previous example's
>> library:
>>
>>
>> packages:
>> - '.'
>> - ../simple-library
>>
>>
>> Then stack build'ing the project (uses-sl) that depends on
>> simple-library which as a module with a warning:
>
>
> Hmmm... that is what I'm doing.  My stack.yaml contains:
>
> packages:
> - normalization-insensitive/
> - photos/
> - unicode-transforms/
>
> The package I'm developing is normalization-insensitive, but I need
> unicode-transforms as a dependency.  (And at the time, unicode-transforms
> was not available on hackage, so I had to check it out locally.)  And then
> photos is a simple application that uses normalization-insensitive.
>
> But when I do "stack build", it does not print the warnings for
> normalization-insensitive.
>
> --Patrick
>



-- 
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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

On 9/14/16 1:10 PM, Christopher Allen wrote:

I see what is meant now, but it's not really applicable. If I am
co-developing a package and its dependencies, I add them as packages
(not deps) to my stack.yaml and still get the warnings.

Example:

 From the stack.yaml for the package that uses my previous example's library:


packages:
- '.'
- ../simple-library


Then stack build'ing the project (uses-sl) that depends on
simple-library which as a module with a warning:


Hmmm... that is what I'm doing.  My stack.yaml contains:

packages:
- normalization-insensitive/
- photos/
- unicode-transforms/

The package I'm developing is normalization-insensitive, but I need 
unicode-transforms as a dependency.  (And at the time, 
unicode-transforms was not available on hackage, so I had to check it 
out locally.)  And then photos is a simple application that uses 
normalization-insensitive.


But when I do "stack build", it does not print the warnings for 
normalization-insensitive.


--Patrick

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

I see what is meant now, but it's not really applicable. If I am
co-developing a package and its dependencies, I add them as packages
(not deps) to my stack.yaml and still get the warnings.

Example:

From the stack.yaml for the package that uses my previous example's library:


packages:
- '.'
- ../simple-library


Then stack build'ing the project (uses-sl) that depends on
simple-library which as a module with a warning:


$ stack build
simple-library-0.1.0.0: build
Progress: 1/2
--  While building package simple-library-0.1.0.0 using:
  
/home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1
--builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build
lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi
-ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to:
/home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log

Preprocessing library simple-library-0.1.0.0...
[1 of 1] Compiling SimpleLib( src/SimpleLib.hs,
.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o )

/home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning:
[-Wunused-do-bind]
A do-notation statement discarded a result of type ‘[Char]’
Suppress this warning by saying ‘_ <- return "hello"’



One of the first things I did when figuring out Stack was to look at
how Yesod used it:
https://github.com/yesodweb/yesod/blob/master/stack.yaml

On Wed, Sep 14, 2016 at 2:56 PM, David McBride  wrote:
> The rule of thumb seems to be, if you do a stack build and it decides to
> build multiple packages, it hides this log info.
>
> I understand why it does that, I should be able to build lens without
> worrying about tons of spurious output, but at the same time it is common
> for me to have an entire tree of packages I'm developing and it often
> obscures errors that are happening in my own packages.  At the very least,
> if it is only building local packages, I'd very much like to see that
> output.
>
> On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier
>  wrote:
>>
>> 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 (
>> Da

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

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

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

Near as I can tell, it _is_ going to stderr just like you'd expect too

$ stack build > log_output
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 "hi"’
Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...
simple-library-0.1.0.0: copy/register
Installing library in
/home/callen/work/simple-library/.stack-work/install/x86_64-linux/lts-7.0/8.0.1/lib/x86_64-linux-ghc-8.0.1/simple-library-0.1.0.0-IZ2irAKiR4w8tX3NVir98W
Installing executable(s) in
/home/callen/work/simple-library/.stack-work/install/x86_64-linux/lts-7.0/8.0.1/bin
Registering simple-library-0.1.0.0...
[ callen@pardalis ~/work/simple-library master ✗ ]
$ stack build 2>&1 > log_output

On Wed, Sep 14, 2016 at 2: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...
>
> 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



-- 
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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[David Feuer]

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.
>>>
>>> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow 
>>> wrote:
>>> > 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 <
>>> p.giarru...@gmail.com>
>>> >> 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
>>> 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 <
>>> p.gia...@gmail.com>
>>> >> >> 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
>>

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Edward Z. Yang]

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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Michael Snoyman]

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.
>>
>> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow  wrote:
>> > 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 <
>> p.giarru...@gmail.com>
>> >> 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
>> 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 <
>> p.gia...@gmail.com>
>> >> >> 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://do

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Simon Marlow]

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.
>
> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow  wrote:
> > 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
> 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  >
> >> >> 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 f

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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.

On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow  wrote:
> 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 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 
>> >> 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
>> >> > problem

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Simon Marlow]

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 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 
> >> 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 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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Michael Snoyman]

There's a pull request in flight now documenting common workflows for doing
non project work with Stack, whether it be the REPL or scripts/single file
programs. It's not complete, but you can view the content at:

https://github.com/haskell-lang/haskell-lang/pull/94

On Tue, Sep 13, 2016, 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 PA

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

On 9/13/16 1:16 PM, Paolo Giarrusso wrote:
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.


That reminds me: another thing I'd like to see (from either cabal or 
stack) is better support for cross-compilation.  Cabal supports 
cross-compilation very poorly; you end up having to do ugly stuff like:


alias mcabal="cabal --with-ghc=x86_64-unknown-linux-musl-ghc 
--with-ld=x86_64-unknown-linux-musl-ld 
--with-gcc=x86_64-unknown-linux-musl-gcc 
--with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg"


and even then, it doesn't work with non-trivial packages.

As far as I know, stack doesn't support cross-compilation at all. (But 
perhaps it's just not documented, or I've missed the documentation.)


--Patrick

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

There are multiple ways to achieve this:

1) The env command being discussed is actually "stack exec env". Though it
includes the full environment rather than stack exclusive. You can use
"stack path" to print the stack exclusive environment. You can also use
"stack path --" to pick specific items from that env.

2) Using "stack exec bash" is a very convenient way as suggested by
Christopher Allen.

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. So if you want to
use cabal on stack installed ghc just setting PATH works fine.

I think stack has a lot of flexibility and features, in fact too many.
Usually there is already a way to achieve something that you want. Though
there are areas where the user experience can be made better including
cosmetic stuff like not throwing confusing or unnecessary warnings.

-harendra


On 14 September 2016 at 01:32, Christopher Allen  wrote:

> 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
> > allber...@gmail.com
> ballb...@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
> ___
> 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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Sven Panne]

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.
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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 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 
>> 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 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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Paolo Giarrusso]

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  > 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 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.
>
>___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Kyle Ondy]

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 dir

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Alberto G. Corona]

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.
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

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
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[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

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, 

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

On Tue, Sep 13, 2016 at 3:14 PM, John Wiegley  wrote:

> 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.
>

There's more to it than $PATH --- and I am not sure that making it easy to
accidentally modify the sandboxed package database is in any way a good
idea.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Chris Smith]

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 
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 ne

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

On Tue, Sep 13, 2016 at 3:13 PM, Kyle Ondy  wrote:

> 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.
>

I actually find this part a little unfair; stack parses its parameters the
same way cabal does.

> stack exec -- ghc --version
> cabal exec -- ghc --version
Both need the -- to prevent --version from being eaten by stack/cabal
respectively. (GNU "permute" argument parsing. urgh.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

Stack isn't exclusively for applications or libraries, the
recommendation to add Cabal to your CI if it's a library is about
checking buildability for Cabal users (making sure your bounds don't
make the solver bonkers), not for workflow.

On Tue, Sep 13, 2016 at 3:08 PM, Paolo Giarrusso  wrote:
> On Tuesday, September 13, 2016 at 8:58:53 PM UTC+2, 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.
>
>
>>
>> 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 think this is insightful, but this is also (in part) about different kind
> of projects: applications versus libraries. Not accidentally, if you
> maintain a Hackage library, stack docs recommend you setup CI with both
> stack and cabal. (Though I'll still use stack for local development for a
> library).
>
> https://docs.haskellstack.org/en/latest/travis_ci/
>
>
> ___
> 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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Paolo Giarrusso]

On Tuesday, September 13, 2016 at 8:58:53 PM UTC+2, 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.
>
 

> 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 think this is insightful, but this is also (in part) about different kind 
of projects: applications versus libraries. Not accidentally, if you 
maintain a Hackage library, stack docs recommend you setup CI with both 
stack and cabal. (Though I'll still use stack for local development for a 
library).

https://docs.haskellstack.org/en/latest/travis_ci/

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

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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.

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 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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://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
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Paolo Giarrusso]

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.
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[John Wiegley]

> "RE" == Richard Eisenberg  writes:

RE> Other minor points:
RE> `stack env` does not work for me: my version of stack does not know how to
RE> `env`. I have version 1.1.2, as installed by `brew install haskell-stack`.
RE> Regardless, there are a variety of ways of establishing the right PATH.

Sorry Richard, that was just a feature idea for the stack people, not anything
I knew about already.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[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 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  > 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