technical thoughts on stack

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

technical thoughts on stack

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

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

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

My approach:

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

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

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

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

At the end, I am helpfully told

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

So I then

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

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

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

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

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

> Invalid option `--version’

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

————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I’m looking forward to hearing your thoughts.

Richard


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

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

Re: 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 <[hidden email]> wrote:
I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

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

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

My approach:

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

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

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

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

At the end, I am helpfully told

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

So I then

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

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

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

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

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

> Invalid option `--version’

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

————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I’m looking forward to hearing your thoughts.

Richard


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

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


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

Re: 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 <[hidden email]>
> wrote:
>
> > I’ve watched the recent back-and-forth about stack with quite a bit of
> > interest (as many of us have). The discussion inspired me to take another
> > look at stack. Here are the results of that foray.
> >
> > First, a disclosure: While I have appreciated the emergence of a new build
> > tool for Haskell, I have never much liked stack. One of my chief goals in
> > taking another look is to understand better why I do not like it.
> >
> > My task: Set up a Haskell environment on a new machine (a Mac). This
> > machine has no Haskell infrastructure on it.
> >
> > My approach:
> >
> > 1. `brew install haskell-stack`. Success.
> >
> > At this point, I do not have a Haskell project I wish to build. Instead, I
> > really just want the ability to run Haskell expressions in GHCi. So I skip
> > `stack new` and go straight to
> >
> > 2. `stack setup`. This succeeds, but prints out some interesting messages
> > along the way, including
> >
> > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of
> > 71c0a55d0a877954d9590e285c0eb861ace2d8cc
> > > Right Nothing
> >
> > At the end, I am helpfully told
> >
> > > To use this GHC and packages outside of a project, consider using:
> > > stack ghc, stack ghci, stack runghc, or stack exec
> > >
> >
> > So I then
> >
> > 3. `stack ghci`. My computer’s first reaction is to say
> >
> > > Run from outside a project, using implicit global project config
> > > Using resolver: lts-6.17 from implicit global project's config file:
> > /home/rae/.stack/global-project/stack.yaml
> > > Error parsing targets: The specified targets matched no packages.
> > > Perhaps you need to run 'stack init'?
> > > Warning: build failed, but optimistically launching GHCi anyway
> > >
> >
> > which doesn’t make me feel all that comfortable, but then I am indeed
> > delivered to the GHCi prompt, which works as expected.
> >
> > Done with GHCi, I quit. I then want to double-check which version of GHC I
> > got, so I
> >
> > 4. `stack ghc --version`. This command reports
> >
> > > Invalid option `--version’
> >
> > Grumble. It seems I can’t interact with GHC directly.
> >
> > ————
> >
> > At this point, I am reminded why I dislike stack:
> >
> > **It’s optimized for a different workflow than I use.**
> >
> > And I think this fact (repeated by others’ experiences) is why a segment
> > of our community has not celebrated stack as much as other segments have.
> > We all have different workflows.
> >
> > From what I understand about it, stack is great for a project-based
> > workflow. In this workflow, you are working on a Haskell project. You are
> > happy to specify settings in .cabal and stack.yaml files. And you really
> > want your build to work in the future and on other machines.
> >
> > In my experience, stack is not great with a compiler-based workflow. In
> > this workflow, you aren’t quite as organized perhaps and do not have all
> > your settings written. You also want the ability just to compile a file
> > without changing any configurations. You want to be able to start GHCi with
> > a nice set of libraries with which to experiment.
> >
> > I definitely like a compiler-based workflow. I’m sure that many of you
> > prefer a project-based workflow.
> >
> > The great news here is that we have a choice: use stack for a
> > project-based workflow, and don’t use it when you want a compiler-based
> > workflow. No one needs to convince others about personal preferences.
> >
> > But there is one nagging issue: what do we suggest to newcomers? The
> > downloads page right now is not serving us well. (I was legitimately
> > scratching my head at first trying to figure out how to provision a new
> > computer.) Sadly, I don’t see a good option presenting itself. Both
> > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion)
> > serious shortcomings.
> >
> > A. The Haskell Toolchain (that is, what’s currently called the Haskell
> > Platform Minimal) does appear to lack a “here’s what you do first”
> > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to
> > discover — you have to choose the oft-maligned Haskell Platform link before
> > you are told that there is a minimal variant.
> >
> > B. stack sets up GHC in a way that either 1) requires a project-based
> > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary
> > warnings every time GHC is invoked outside of a project. Furthermore, stack
> > prohibits direct interaction with GHC (as in `ghc --version`).
> >
> > There’s more good news here! Both of these problems are really easy to fix.
> >
> > To fix (A), someone just has to write the tutorial.
> >
> > To fix (B), stack just needs a new option so that `stack setup` installs a
> > system GHC. Perhaps it would even be sufficient for `stack setup` to
> > clearly tell the user where ghc is installed and what to add to their PATH.
> >
> > I also think, if readers agree with my conclusions about workflows, we
> > should consider writing up criteria that potential users should consider
> > when choosing what workflow to start with. We’ll need to have a tighter
> > recommendation for those with no experience programming, but most
> > developers should be able to recognize what workflow they prefer and choose
> > accordingly.
> >
> > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then
> > we’ll really be in a quandary about which installation procedure to put
> > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever
> > one happens first gets to be featured first on the page? :)
> >
> > So: Does my characterization of workflows resonate? Have I perhaps
> > identified part of the burning black heart of the reason behind the vitriol
> > of late? Should we fix (A) and (B)?
> >
> > I’m looking forward to hearing your thoughts.
> >
> > Richard
> >
> >
> > -=-=-=-=-=-=-=-=-=-=-
> > Richard A. Eisenberg
> > Asst. Prof. of Computer Science
> > Bryn Mawr College
> > Bryn Mawr, PA, USA
> > cs.brynmawr.edu/~rae
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.

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


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

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

Re: [Haskell-community] technical thoughts on stack

John Wiegley-2
In reply to this post by Richard Eisenberg-4
>>>>> "RE" == Richard Eisenberg <[hidden email]> 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.

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Brandon Allbery
In reply to this post by Kyle Ondy
On Tue, Sep 13, 2016 at 3:13 PM, Kyle Ondy <[hidden email]> 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
[hidden email]                                  [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-community] technical thoughts on stack

Brandon Allbery
In reply to this post by John Wiegley-2

On Tue, Sep 13, 2016 at 3:14 PM, John Wiegley <[hidden email]> 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
[hidden email]                                  [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Chris Smith-31
In reply to this post by Richard Eisenberg-4
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 <[hidden email]> wrote:
I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

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

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

My approach:

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

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

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

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

At the end, I am helpfully told

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

So I then

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

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

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

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

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

> Invalid option `--version’

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

————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I’m looking forward to hearing your thoughts.

Richard


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

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


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

Re: [Haskell-community] technical thoughts on stack

Alberto G. Corona
In reply to this post by John Wiegley-2


2016-09-13 21:14 GMT+02:00 John Wiegley <[hidden email]>:
>>>>> "RE" == Richard Eisenberg <[hidden email]> 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-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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Richard Eisenberg-4
In reply to this post by Chris Smith-31
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 <[hidden email]> 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 <[hidden email]> wrote:
I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.

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

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

My approach:

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

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

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

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

At the end, I am helpfully told

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

So I then

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

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

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

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

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

> Invalid option `--version’

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

————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I’m looking forward to hearing your thoughts.

Richard


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

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



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

Re: technical thoughts on stack

Brandon Allbery

On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg <[hidden email]> 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
[hidden email]                                  [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-community] technical thoughts on stack

John Wiegley-2
In reply to this post by Richard Eisenberg-4
>>>>> "RE" == Richard Eisenberg <[hidden email]> 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-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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Paolo Giarrusso
In reply to this post by Richard Eisenberg-4


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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Christopher Allen
In reply to this post by Brandon Allbery
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 <[hidden email]> wrote:

>
> On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Christopher Allen
In reply to this post by Paolo Giarrusso
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Paolo Giarrusso
In reply to this post by Richard Eisenberg-4
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-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.
Reply | Threaded
Open this post in threaded view
|

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



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

Re: technical thoughts on stack

Paolo Giarrusso
In reply to this post by Christopher Allen
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="M_qSMCr2AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">p.gia...@...> 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
> <a href="https://docs.haskellstack.org/en/latest/faq/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.haskellstack.org%2Fen%2Flatest%2Ffaq%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFOQsXj2vn9xd87qv5H1CS8LUEZYw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.haskellstack.org%2Fen%2Flatest%2Ffaq%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFOQsXj2vn9xd87qv5H1CS8LUEZYw&#39;;return true;">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:
> <a href="https://github.com/commercialhaskell/stack/issues/2546" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fstack%2Fissues%2F2546\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGsJi8ewoYU1JsKuTR7ThuhsV2q6g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fstack%2Fissues%2F2546\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGsJi8ewoYU1JsKuTR7ThuhsV2q6g&#39;;return true;">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:
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-cafe\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH7sFgl7KfuDcDlaGGG3ip3kRaoIA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-cafe\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH7sFgl7KfuDcDlaGGG3ip3kRaoIA&#39;;return true;">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 <a href="http://haskellbook.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fhaskellbook.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG46wU2oFQDecd0YpDIDIGbtyVs1Q&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fhaskellbook.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG46wU2oFQDecd0YpDIDIGbtyVs1Q&#39;;return true;">http://haskellbook.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-cafe\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH7sFgl7KfuDcDlaGGG3ip3kRaoIA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-cafe\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH7sFgl7KfuDcDlaGGG3ip3kRaoIA&#39;;return true;">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


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

Re: technical thoughts on stack

Sven Panne-2
In reply to this post by Theodore Lief Gannon
2016-09-13 21:07 GMT+02:00 Theodore Lief Gannon <[hidden email]>:
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-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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Christopher Allen
In reply to this post by Paolo Giarrusso
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 <[hidden email]> 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 <[hidden email]>
>> 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-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.
Reply | Threaded
Open this post in threaded view
|

Re: technical thoughts on stack

Harendra Kumar
In reply to this post by Christopher Allen
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 --<flag>" 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 <[hidden email]> 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 <[hidden email]> wrote:
>
> On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> 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-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.
1234