From michael at fpcomplete.com Thu Sep 1 04:37:22 2016 From: michael at fpcomplete.com (Michael Snoyman) Date: Thu, 1 Sep 2016 07:37:22 +0300 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: On Thu, Sep 1, 2016 at 12:41 AM, Nicolas Wu wrote: > Hi Paolo, > > On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso > wrote: > >> > The decision about how to manage projects and their dependencies should >> be >> > open and isn't for beginners, whether that be using stack or cabal: both >> > have their merits, and I don't want to push one over the other. >> >> I'm honestly confused what you're arguing. You say this decision isn't >> for beginners, yet you propose offering the HP. So how should a >> beginner install a package without first deciding whether to use >> cabal-install or stack? Or can a beginner meaningfully be expected to >> learn using both alternatives? >> > > Sorry for not being clear, my bad. Hopefully I can clarify and elaborate a > bit more. > > I think a beginner doesn't usually make the choice of how to use > GHC/stack/cabal by themselves; they are usually being instructed by someone > (or a resource) that has decided that for them. > I disagree, and that's where a lot of this debate comes from. Let me give an example from another language. Suppose you know nothing about Rust, and decide you want to learn Rust because you see a blog post talking about how awesome Rust is (with no specific link to "get started here," which is frequently the case). You'd probably go to Google and search "Rust programming language," and show up on their homepage. They have two links that stand out (to me at least): * A big "Download" button, which provides the compiler and build tool (AFAICT it does not include non-standard libraries, so pretty equivalent to HP Minimal) * A "Show me" link taking you straight to a tutorial, which covers both command line invocation for the compiler _and_ the build tool This is the documentation issue I've raised a few times: a new user coming from nowhere has no way of really getting started with Haskell after downloading the platform. _Some_ kind of "go here next" is necessary if we want to improve the new Haskeller bounce rate (which is all I'm concerned with). By that metric, a solid "how to get far in Haskell with just standard libraries and the ghc executable" would work, as would a tutorial on "writing applications with HP and cabal-install." However, based on my experience working with new users (both through Yesod, general Haskell work, and at my day job), I believe that Stack covers the job best, since: 1. The Haskell standard libraries are very bare bones, so most users will quickly want an additional library, even just for experimenting 2. I still see users complaining about dependency solving problems with cabal-install, and new users will likely be turned off very quickly by that 3. Stack+curated package sets has produced much lower friction in these regards 4. Stack already has a quick start guide ( https://docs.haskellstack.org/en/stable/README/#quick-start-guide), in-depth guide (https://docs.haskellstack.org/en/stable/GUIDE/), and has usage covered by books and tutorials. I don't believe a holistic workflow is included in the HP or the Cabal websites for cabal-install workflow (though if I'm mistaken, please point it out, that would be an interesting comparison). Michael PS: The hypothetical example of "reads a great Rust blog post and gets interested" is _exactly_ what I'm hoping to cause to happen in the Haskell community. I want to encourage lots of people to write great content on why Haskell is an amazing language that will solve so many real world problems. My big concern with the direction of haskell.org is that these new users will end up hitting a brick wall very quickly with the content on the site right now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.wu at gmail.com Thu Sep 1 06:17:55 2016 From: nicolas.wu at gmail.com (Nicolas Wu) Date: Thu, 01 Sep 2016 06:17:55 +0000 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: Hello Michael, On Thu, Sep 1, 2016 at 6:37 AM Michael Snoyman wrote: > On Thu, Sep 1, 2016 at 12:41 AM, Nicolas Wu wrote: >> >> I think a beginner doesn't usually make the choice of how to use >> GHC/stack/cabal by themselves; they are usually being instructed by someone >> (or a resource) that has decided that for them. >> > > I disagree, and that's where a lot of this debate comes from. Let me give > an example from another language. Suppose you know nothing about Rust, and > decide you want to learn Rust because you see a blog post talking about how > awesome Rust is (with no specific link to "get started here," which is > frequently the case). You'd probably go to Google and search "Rust > programming language," and show up on their homepage. They have two links > that stand out (to me at least): > > * A big "Download" button, which provides the compiler and build tool > (AFAICT it does not include non-standard libraries, so pretty equivalent to > HP Minimal) > * A "Show me" link taking you straight to a tutorial, which covers both > command line invocation for the compiler _and_ the build tool > > This is the documentation issue I've raised a few times: a new user coming > from nowhere has no way of really getting started with Haskell after > downloading the platform. _Some_ kind of "go here next" is necessary if we > want to improve the new Haskeller bounce rate (which is all I'm concerned > with). By that metric, a solid "how to get far in Haskell with just > standard libraries and the ghc executable" would work, as would a tutorial > on "writing applications with HP and cabal-install." > If I've understood you correctly, I agree on this point: we should be providing a single download that contains something equivalent to the HP Minimal. That's what I'm suggesting. I also agree that pointing to a tutorial that outlines how to actually use the tools is useful. However, based on my experience working with new users (both through Yesod, > general Haskell work, and at my day job), I believe that Stack covers the > job best, since: > > 1. The Haskell standard libraries are very bare bones, so most users will > quickly want an additional library, even just for experimenting > 2. I still see users complaining about dependency solving problems with > cabal-install, and new users will likely be turned off very quickly by that > 3. Stack+curated package sets has produced much lower friction in these > regards > 4. Stack already has a quick start guide ( > https://docs.haskellstack.org/en/stable/README/#quick-start-guide), > in-depth guide (https://docs.haskellstack.org/en/stable/GUIDE/), and has > usage covered by books and tutorials. I don't believe a holistic workflow > is included in the HP or the Cabal websites for cabal-install workflow > (though if I'm mistaken, please point it out, that would be an interesting > comparison). > This is where I think you and I have different use cases, and where I'm advocating diversity that will allow us both to teach as we like. In my experience as a university lecturer that teaches students learning Haskell in the first term of their first year, I have a different approach that has also seen success. My initial tutorials require students to invoke ghc and ghci to familiarise themselves with the concepts of compilers and interpreters. They do so on small self-contained exercises. I'm at the same time trying to get them used to the command line, since for many this will be their first experience of any development at all. They need a simple workflow at this point since they are already dealing with so many different issues. Later exercises that involve a very small project use cabal, but for the most part this is redundant: our university machines are pre-configured with all the packages I know they'll need for the tasks they need. I try to avoid having them deal with dependency issues at all, since that's an area that's tangential to learning about functional programming and they have so much to learn and understand at this point. Let me stress that I'm not trying to change the way you teach the newcomers you encounter, I'm just saying that I approach this differently (I suspect that it's because the beginners you're describing are newcomers to Haskell who already have some programming experience). When my students hit the downloads page to install Haskell on their own machines, I want them to find at least a minimal toolchain that contains a compiler and an interpreter. PS: The hypothetical example of "reads a great Rust blog post and gets > interested" is _exactly_ what I'm hoping to cause to happen in the Haskell > community. I want to encourage lots of people to write great content on why > Haskell is an amazing language that will solve so many real world problems. > My big concern with the direction of haskell.org is that these new users > will end up hitting a brick wall very quickly with the content on the site > right now. > I want to build up a good community too, and I am grateful the efforts that have been put into technologies like stack and cabal. I want to explicitly acknowledge and appreciate all the hard work that you and other people have been putting into improving our infrastructure: what we have is a very valuable resource. I also think the site needs improving, so let's work to fix that. I'm obviously aware that you have been unhappy with the decisions the committee has made on this issue, and I'm sorry you've been upset. I can only assure you that you have been listened to in the past and that we will continue to listen. I think our goal is to foster a community that embraces our common interests and accepts diversity. Best wishes, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyday567 at gmail.com Thu Sep 1 06:31:17 2016 From: tonyday567 at gmail.com (Tony Day) Date: Thu, 01 Sep 2016 06:31:17 +0000 Subject: [Haskell-community] Bounce rate Message-ID: What might be useful is knowing what the visitor stats are, and the new visitor bounce rate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at fpcomplete.com Thu Sep 1 06:49:12 2016 From: michael at fpcomplete.com (Michael Snoyman) Date: Thu, 1 Sep 2016 09:49:12 +0300 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: Thank you for the thoughtful reply Nick. On Thu, Sep 1, 2016 at 9:17 AM, Nicolas Wu wrote: > Hello Michael, > > On Thu, Sep 1, 2016 at 6:37 AM Michael Snoyman > wrote: > >> On Thu, Sep 1, 2016 at 12:41 AM, Nicolas Wu wrote: >>> >>> I think a beginner doesn't usually make the choice of how to use >>> GHC/stack/cabal by themselves; they are usually being instructed by someone >>> (or a resource) that has decided that for them. >>> >> >> I disagree, and that's where a lot of this debate comes from. Let me give >> an example from another language. Suppose you know nothing about Rust, and >> decide you want to learn Rust because you see a blog post talking about how >> awesome Rust is (with no specific link to "get started here," which is >> frequently the case). You'd probably go to Google and search "Rust >> programming language," and show up on their homepage. They have two links >> that stand out (to me at least): >> >> * A big "Download" button, which provides the compiler and build tool >> (AFAICT it does not include non-standard libraries, so pretty equivalent to >> HP Minimal) >> * A "Show me" link taking you straight to a tutorial, which covers both >> command line invocation for the compiler _and_ the build tool >> >> This is the documentation issue I've raised a few times: a new user >> coming from nowhere has no way of really getting started with Haskell after >> downloading the platform. _Some_ kind of "go here next" is necessary if we >> want to improve the new Haskeller bounce rate (which is all I'm concerned >> with). By that metric, a solid "how to get far in Haskell with just >> standard libraries and the ghc executable" would work, as would a tutorial >> on "writing applications with HP and cabal-install." >> > > If I've understood you correctly, I agree on this point: we should be > providing a single download that contains something equivalent to the HP > Minimal. That's what I'm suggesting. I also agree that pointing to a > tutorial that outlines how to actually use the tools is useful. > > I'd be far less concerned about HP Minimal if: 1. Having a tutorial go along with it was a prereq to bumping its position. 2. The issues that Stack users have been running into are addressed first. There _are_ bug reports coming into the Stack issue tracker about this (like there were with GHC for Mac OS X previously), and this is an undue burden to place on the Stack maintainers. My reason for an immediate -1 on the proposal is that, as it stands today, I would describe the HP Minimal content on haskell.org/downloads as a "brick wall" for anyone not following a preexisting guide. (And for someone already following a different guide: who cares what haskell.org says? They'll just follow the guide.) > However, based on my experience working with new users (both through >> Yesod, general Haskell work, and at my day job), I believe that Stack >> covers the job best, since: >> >> 1. The Haskell standard libraries are very bare bones, so most users will >> quickly want an additional library, even just for experimenting >> 2. I still see users complaining about dependency solving problems with >> cabal-install, and new users will likely be turned off very quickly by that >> 3. Stack+curated package sets has produced much lower friction in these >> regards >> 4. Stack already has a quick start guide (https://docs.haskellstack. >> org/en/stable/README/#quick-start-guide), in-depth guide ( >> https://docs.haskellstack.org/en/stable/GUIDE/), and has usage covered >> by books and tutorials. I don't believe a holistic workflow is included in >> the HP or the Cabal websites for cabal-install workflow (though if I'm >> mistaken, please point it out, that would be an interesting comparison). >> > > This is where I think you and I have different use cases, and where I'm > advocating diversity that will allow us both to teach as we like. > > In my experience as a university lecturer that teaches students learning > Haskell in the first term of their first year, I have a different approach > that has also seen success. My initial tutorials require students to invoke > ghc and ghci to familiarise themselves with the concepts of compilers and > interpreters. They do so on small self-contained exercises. I'm at the > same time trying to get them used to the command line, since for many this > will be their first experience of any development at all. They need a > simple workflow at this point since they are already dealing with so many > different issues. Later exercises that involve a very small project use > cabal, but for the most part this is redundant: our university machines are > pre-configured with all the packages I know they'll need for the tasks they > need. I try to avoid having them deal with dependency issues at all, since > that's an area that's tangential to learning about functional programming > and they have so much to learn and understand at this point. > > Let me stress that I'm not trying to change the way you teach the > newcomers you encounter, I'm just saying that I approach this differently > (I suspect that it's because the beginners you're describing are newcomers > to Haskell who already have some programming experience). When my students > hit the downloads page to install Haskell on their own machines, I want > them to find at least a minimal toolchain that contains a compiler and an > interpreter. > > I don't think this tension between goals actually exists. Have you ever worked with students using Stack? The differences are minor: * Both HP Minimal and Stack have clear installation instructions. We can argue about which one is easier, there are issues of root user access that need to be discussed. * If you want a repl, you just run `stack ghci` (or, if you want more control, `stack exec ghci`). I honestly doubt that _this_ is the pain point that prevents a user from succeeding with the repl. If you have contradicting experiences, I'd be happy to hear them. But in my work with people - granted mostly people who are already command line comfortable - this isn't a big deal. In fact, it's more of a problem for _existing_ Haskellers who are used to running `ghci` directly. Beyond that are plenty of arguments around more easily accessing other packages, e.g. `stack ghci --package turtle` is very straightforward. How would you recommend achieving the same thing in a cabal-install world? 1. You could install without a sandbox, but that's not recommended 2. You could teach the user to `cabal sandbox init; cabal install turtle; cabal repl`. But that's clearly more complex, has complications of dependency solving, and defeats the whole idea of having tools readily available 3. You could go the new-build route. But my understanding (I could be wrong) is that the story around package selection for ghci/runghc when using the nix-style databases is not fully worked out yet. I'd like to see these very real and common use cases discussed and worked out before we decide that one way is easier or harder for a new user. Sure, if we know that every single user will just be compiling and running Hello World with only the standard library and will only need the version of GHC provided on the downloads page, HP Minimal wins hands down. I think that's a very restricted niche. > PS: The hypothetical example of "reads a great Rust blog post and gets >> interested" is _exactly_ what I'm hoping to cause to happen in the Haskell >> community. I want to encourage lots of people to write great content on why >> Haskell is an amazing language that will solve so many real world problems. >> My big concern with the direction of haskell.org is that these new users >> will end up hitting a brick wall very quickly with the content on the site >> right now. >> > > I want to build up a good community too, and I am grateful the efforts > that have been put into technologies like stack and cabal. I want to > explicitly acknowledge and appreciate all the hard work that you and other > people have been putting into improving our infrastructure: what we have is > a very valuable resource. I also think the site needs improving, so let's > work to fix that. > > I'm obviously aware that you have been unhappy with the decisions the > committee has made on this issue, and I'm sorry you've been upset. I can > only assure you that you have been listened to in the past and that we will > continue to listen. I think our goal is to foster a community that embraces > our common interests and accepts diversity. > > > Thank you, I'm really glad to be having this technical level of conversation. If we actually talk out the points and make clear what everyone's goals are, I don't think it's unreasonable at all to come up with a solution that everyone is happy with. Having more involvement from the rest of the committee on this discussion is great. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Sep 1 07:09:02 2016 From: gershomb at gmail.com (Gershom B) Date: Thu, 1 Sep 2016 03:09:02 -0400 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: I think this is a very good point being made. We should disengangle the installer question from the “getting started” question.  Someone on reddit even proposed having two seperate pages entirely. A getting started page that promoted a stack centric workflow for beginners as a good “default path” would be reasonable in my eyes, and certainly worth discussing. Certainly if it let us lay the downloads page to rest with a single option for a minimal installer (with perhaps slightly different branding as discussed on a ticket I linked earlier — “Haskell Toolchain” or the like) that provided ghc, stack and cabal all, then I think that would be a very good way to go. That way Nicolas and others who wanted to direct people to the downloads page, and then wanted to teach them with one sort of approach would be able to do so, people who wanted to direct people to the downloads page, and teach them with a stack-based approach would be able to do so, and people coming to the site directly could immediately find a “getting started page” with a single approach that got them up and running quickly, and that approach could well be stack-oriented if that’s what people think gives the best experience for that particular use case. (Again, I give the caveat I’m speaking just for myself here, and thinking this through as an idea I’d like to hear others’ thoughts on). —gershom On August 31, 2016 at 5:48:41 PM, Nicolas Wu (nicolas.wu at gmail.com) wrote: > Hi Paolo, > > On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso > wrote: > > > > The decision about how to manage projects and their dependencies should > > be > > > open and isn't for beginners, whether that be using stack or cabal: both > > > have their merits, and I don't want to push one over the other. > > > > I'm honestly confused what you're arguing. You say this decision isn't > > for beginners, yet you propose offering the HP. So how should a > > beginner install a package without first deciding whether to use > > cabal-install or stack? Or can a beginner meaningfully be expected to > > learn using both alternatives? > > > > Sorry for not being clear, my bad. Hopefully I can clarify and elaborate a > bit more. > > I think a beginner doesn't usually make the choice of how to use > GHC/stack/cabal by themselves; they are usually being instructed by someone > (or a resource) that has decided that for them. On that front I don't think > there's a singular best way to approach this; there's diversity in the way > people approach teaching and that's fine and healthy, there's also > diversity in the way people learn and the goals they have with the language > and that's fine and healthy too. We should be supporting people who want to > learn the language as well as people who want to contribute to teaching. We > should respect diversity in those roles; if someone wants their students to > use only stack then by all means they can do so, that shouldn't stop others > from using ghc or ghci directly. > > For instance, if a beginner is just trying to run small examples they see > on a blog, then maybe all they need is a call to ghci. If they're learning > about making a simple binary they might want ghc. If they want to have a > whole managed project, perhaps they're after either stack or cabal. The > point is that they're usually guided by something, and those guides do > differ on what they prefer and recommend. The default download should > easily support these different modes of learning and teaching. > > > > Also, do both tools have their merits *for beginners*? We're talking > > of cabal as-is, not of the ongoing work on new-build. > > > > I'm talking about having a default that bundles tools like ghc, cabal, and > stack, since these are the main tools our community has for compiling and > executing Haskell code. I don't want to force people into one of > these--whether that be students or educators. In all cases the default > download recommendation should support all of these since they are the > mainstream tools we use. To avoid confusion I think there should be only > one recommended option on the main download page (and here the HP minimal > seems to satisfy this, and stack seems to preclude this). The download page > should also have a link to other resources (such as the HP Full, stack > only, and other distributions like Haskell for Mac) on another page. > > Since there seems to be confusion about how the committee comes to a > consensus I should note that at this point I'm only speaking for myself > here. This is just my recommendation, and I'm open and willing to listen to > other views before considering what I think is best. I am not usually > overtly vocal in these discussions, but I do read what is said and form my > own opinions. > > Best wishes, > > Nick > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > From gershomb at gmail.com Thu Sep 1 07:18:59 2016 From: gershomb at gmail.com (Gershom B) Date: Thu, 1 Sep 2016 03:18:59 -0400 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: I think this is a very good point being made. We should disengangle the installer question from the “getting started” question.  Someone on reddit even proposed having two seperate pages entirely. A getting started page that promoted a stack centric workflow for beginners as a good “default path” would be reasonable in my eyes, and certainly worth discussing. Certainly if it let us lay the downloads page to rest with a single option for a minimal installer (with perhaps slightly different branding as discussed on a ticket I linked earlier — “Haskell Toolchain” or the like) that provided ghc, stack and cabal all, then I think that would be a very good way to go. That way Nicolas and others who wanted to direct people to the downloads page, and then wanted to teach them with one sort of approach would be able to do so, people who wanted to direct people to the downloads page, and teach them with a stack-based approach would be able to do so, and people coming to the site directly could immediately find a “getting started page” with a single approach that got them up and running quickly, and that approach could well be stack-oriented if that’s what people think gives the best experience for that particular use case. (Again, I give the caveat I’m speaking just for myself here, and thinking this through as an idea I’d like to hear others’ thoughts on). —gershom On August 31, 2016 at 5:48:41 PM, Nicolas Wu (nicolas.wu at gmail.com) wrote: > Hi Paolo, > > On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso > wrote: > > > > The decision about how to manage projects and their dependencies should > > be > > > open and isn't for beginners, whether that be using stack or cabal: both > > > have their merits, and I don't want to push one over the other. > > > > I'm honestly confused what you're arguing. You say this decision isn't > > for beginners, yet you propose offering the HP. So how should a > > beginner install a package without first deciding whether to use > > cabal-install or stack? Or can a beginner meaningfully be expected to > > learn using both alternatives? > > > > Sorry for not being clear, my bad. Hopefully I can clarify and elaborate a > bit more. > > I think a beginner doesn't usually make the choice of how to use > GHC/stack/cabal by themselves; they are usually being instructed by someone > (or a resource) that has decided that for them. On that front I don't think > there's a singular best way to approach this; there's diversity in the way > people approach teaching and that's fine and healthy, there's also > diversity in the way people learn and the goals they have with the language > and that's fine and healthy too. We should be supporting people who want to > learn the language as well as people who want to contribute to teaching. We > should respect diversity in those roles; if someone wants their students to > use only stack then by all means they can do so, that shouldn't stop others > from using ghc or ghci directly. > > For instance, if a beginner is just trying to run small examples they see > on a blog, then maybe all they need is a call to ghci. If they're learning > about making a simple binary they might want ghc. If they want to have a > whole managed project, perhaps they're after either stack or cabal. The > point is that they're usually guided by something, and those guides do > differ on what they prefer and recommend. The default download should > easily support these different modes of learning and teaching. > > > > Also, do both tools have their merits *for beginners*? We're talking > > of cabal as-is, not of the ongoing work on new-build. > > > > I'm talking about having a default that bundles tools like ghc, cabal, and > stack, since these are the main tools our community has for compiling and > executing Haskell code. I don't want to force people into one of > these--whether that be students or educators. In all cases the default > download recommendation should support all of these since they are the > mainstream tools we use. To avoid confusion I think there should be only > one recommended option on the main download page (and here the HP minimal > seems to satisfy this, and stack seems to preclude this). The download page > should also have a link to other resources (such as the HP Full, stack > only, and other distributions like Haskell for Mac) on another page. > > Since there seems to be confusion about how the committee comes to a > consensus I should note that at this point I'm only speaking for myself > here. This is just my recommendation, and I'm open and willing to listen to > other views before considering what I think is best. I am not usually > overtly vocal in these discussions, but I do read what is said and form my > own opinions. > > Best wishes, > > Nick > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > From michael at fpcomplete.com Thu Sep 1 07:30:10 2016 From: michael at fpcomplete.com (Michael Snoyman) Date: Thu, 01 Sep 2016 07:30:10 +0000 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: This sounds awesome, I'm totally behind it. Thank you Gershom! On Thu, Sep 1, 2016, 10:09 AM Gershom B wrote: > I think this is a very good point being made. We should disengangle > the installer question from the “getting started” question. Someone > on reddit even proposed having two seperate pages entirely. > > A getting started page that promoted a stack centric workflow for > beginners as a good “default path” would be reasonable in my eyes, and > certainly worth discussing. Certainly if it let us lay the downloads > page to rest with a single option for a minimal installer (with > perhaps slightly different branding as discussed on a ticket I linked > earlier — “Haskell Toolchain” or the like) that provided ghc, stack > and cabal all, then I think that would be a very good way to go. > > That way Nicolas and others who wanted to direct people to the > downloads page, and then wanted to teach them with one sort of > approach would be able to do so, people who wanted to direct people to > the downloads page, and teach them with a stack-based approach would > be able to do so, and people coming to the site directly could > immediately find a “getting started page” with a single approach that > got them up and running quickly, and that approach could well be > stack-oriented if that’s what people think gives the best experience > for that particular use case. > > (Again, I give the caveat I’m speaking just for myself here, and > thinking this through as an idea I’d like to hear others’ thoughts > on). > > —gershom > > > On August 31, 2016 at 5:48:41 PM, Nicolas Wu (nicolas.wu at gmail.com) wrote: > > Hi Paolo, > > > > On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso > > wrote: > > > > > > The decision about how to manage projects and their dependencies > should > > > be > > > > open and isn't for beginners, whether that be using stack or cabal: > both > > > > have their merits, and I don't want to push one over the other. > > > > > > I'm honestly confused what you're arguing. You say this decision isn't > > > for beginners, yet you propose offering the HP. So how should a > > > beginner install a package without first deciding whether to use > > > cabal-install or stack? Or can a beginner meaningfully be expected to > > > learn using both alternatives? > > > > > > > Sorry for not being clear, my bad. Hopefully I can clarify and elaborate > a > > bit more. > > > > I think a beginner doesn't usually make the choice of how to use > > GHC/stack/cabal by themselves; they are usually being instructed by > someone > > (or a resource) that has decided that for them. On that front I don't > think > > there's a singular best way to approach this; there's diversity in the > way > > people approach teaching and that's fine and healthy, there's also > > diversity in the way people learn and the goals they have with the > language > > and that's fine and healthy too. We should be supporting people who want > to > > learn the language as well as people who want to contribute to teaching. > We > > should respect diversity in those roles; if someone wants their students > to > > use only stack then by all means they can do so, that shouldn't stop > others > > from using ghc or ghci directly. > > > > For instance, if a beginner is just trying to run small examples they see > > on a blog, then maybe all they need is a call to ghci. If they're > learning > > about making a simple binary they might want ghc. If they want to have a > > whole managed project, perhaps they're after either stack or cabal. The > > point is that they're usually guided by something, and those guides do > > differ on what they prefer and recommend. The default download should > > easily support these different modes of learning and teaching. > > > > > > > Also, do both tools have their merits *for beginners*? We're talking > > > of cabal as-is, not of the ongoing work on new-build. > > > > > > > I'm talking about having a default that bundles tools like ghc, cabal, > and > > stack, since these are the main tools our community has for compiling and > > executing Haskell code. I don't want to force people into one of > > these--whether that be students or educators. In all cases the default > > download recommendation should support all of these since they are the > > mainstream tools we use. To avoid confusion I think there should be only > > one recommended option on the main download page (and here the HP minimal > > seems to satisfy this, and stack seems to preclude this). The download > page > > should also have a link to other resources (such as the HP Full, stack > > only, and other distributions like Haskell for Mac) on another page. > > > > Since there seems to be confusion about how the committee comes to a > > consensus I should note that at this point I'm only speaking for myself > > here. This is just my recommendation, and I'm open and willing to listen > to > > other views before considering what I think is best. I am not usually > > overtly vocal in these discussions, but I do read what is said and form > my > > own opinions. > > > > Best wishes, > > > > Nick > > _______________________________________________ > > Haskell-community mailing list > > Haskell-community at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Thu Sep 1 07:38:42 2016 From: johnw at newartisans.com (John Wiegley) Date: Thu, 01 Sep 2016 00:38:42 -0700 Subject: [Haskell-community] haskell.org download page In-Reply-To: (Michael Snoyman's message of "Thu, 1 Sep 2016 09:49:12 +0300") References: Message-ID: >>>>> "MS" == Michael Snoyman writes: MS> Thank you, I'm really glad to be having this technical level of MS> conversation. If we actually talk out the points and make clear what MS> everyone's goals are, I don't think it's unreasonable at all to come up MS> with a solution that everyone is happy with. Having more involvement from MS> the rest of the committee on this discussion is great. I'm very glad to hear you say this Michael. Creating a positive Haskell experience for others is my only reason to want to be involved on this committee. If we can all work together to achieve a better state of affairs (and I think we universally agree things need improving), this would cause me great joy. I don't have any particular ideas on the download page right now, apart from what's been said already, but when I do, I'll chime in. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From mightybyte at gmail.com Thu Sep 1 07:40:47 2016 From: mightybyte at gmail.com (MightyByte) Date: Thu, 1 Sep 2016 03:40:47 -0400 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: I also think the downloads should be the minimal HP and separated from getting started. But that doesn't mean we can't bridge the gap with a simple link at the bottom of the downloads page pointing people to the next step: "Next...get started with Haskell" or something similar. Then I'm sure we can come up with a getting started page that has links to different tracks targeted at different audiences. Based on this discussion I can think of three obvious getting started tracks: Total beginner command line ghci Cabal-install Stack And we can even present them horizontally so they all are presented at the same time and on the same level! On Thu, Sep 1, 2016 at 3:30 AM, Michael Snoyman wrote: > This sounds awesome, I'm totally behind it. Thank you Gershom! > > > On Thu, Sep 1, 2016, 10:09 AM Gershom B wrote: >> >> I think this is a very good point being made. We should disengangle >> the installer question from the “getting started” question. Someone >> on reddit even proposed having two seperate pages entirely. >> >> A getting started page that promoted a stack centric workflow for >> beginners as a good “default path” would be reasonable in my eyes, and >> certainly worth discussing. Certainly if it let us lay the downloads >> page to rest with a single option for a minimal installer (with >> perhaps slightly different branding as discussed on a ticket I linked >> earlier — “Haskell Toolchain” or the like) that provided ghc, stack >> and cabal all, then I think that would be a very good way to go. >> >> That way Nicolas and others who wanted to direct people to the >> downloads page, and then wanted to teach them with one sort of >> approach would be able to do so, people who wanted to direct people to >> the downloads page, and teach them with a stack-based approach would >> be able to do so, and people coming to the site directly could >> immediately find a “getting started page” with a single approach that >> got them up and running quickly, and that approach could well be >> stack-oriented if that’s what people think gives the best experience >> for that particular use case. >> >> (Again, I give the caveat I’m speaking just for myself here, and >> thinking this through as an idea I’d like to hear others’ thoughts >> on). >> >> —gershom >> >> >> On August 31, 2016 at 5:48:41 PM, Nicolas Wu (nicolas.wu at gmail.com) wrote: >> > Hi Paolo, >> > >> > On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso >> > wrote: >> > >> > > > The decision about how to manage projects and their dependencies >> > > > should >> > > be >> > > > open and isn't for beginners, whether that be using stack or cabal: >> > > > both >> > > > have their merits, and I don't want to push one over the other. >> > > >> > > I'm honestly confused what you're arguing. You say this decision isn't >> > > for beginners, yet you propose offering the HP. So how should a >> > > beginner install a package without first deciding whether to use >> > > cabal-install or stack? Or can a beginner meaningfully be expected to >> > > learn using both alternatives? >> > > >> > >> > Sorry for not being clear, my bad. Hopefully I can clarify and elaborate >> > a >> > bit more. >> > >> > I think a beginner doesn't usually make the choice of how to use >> > GHC/stack/cabal by themselves; they are usually being instructed by >> > someone >> > (or a resource) that has decided that for them. On that front I don't >> > think >> > there's a singular best way to approach this; there's diversity in the >> > way >> > people approach teaching and that's fine and healthy, there's also >> > diversity in the way people learn and the goals they have with the >> > language >> > and that's fine and healthy too. We should be supporting people who want >> > to >> > learn the language as well as people who want to contribute to teaching. >> > We >> > should respect diversity in those roles; if someone wants their students >> > to >> > use only stack then by all means they can do so, that shouldn't stop >> > others >> > from using ghc or ghci directly. >> > >> > For instance, if a beginner is just trying to run small examples they >> > see >> > on a blog, then maybe all they need is a call to ghci. If they're >> > learning >> > about making a simple binary they might want ghc. If they want to have a >> > whole managed project, perhaps they're after either stack or cabal. The >> > point is that they're usually guided by something, and those guides do >> > differ on what they prefer and recommend. The default download should >> > easily support these different modes of learning and teaching. >> > >> > >> > > Also, do both tools have their merits *for beginners*? We're talking >> > > of cabal as-is, not of the ongoing work on new-build. >> > > >> > >> > I'm talking about having a default that bundles tools like ghc, cabal, >> > and >> > stack, since these are the main tools our community has for compiling >> > and >> > executing Haskell code. I don't want to force people into one of >> > these--whether that be students or educators. In all cases the default >> > download recommendation should support all of these since they are the >> > mainstream tools we use. To avoid confusion I think there should be only >> > one recommended option on the main download page (and here the HP >> > minimal >> > seems to satisfy this, and stack seems to preclude this). The download >> > page >> > should also have a link to other resources (such as the HP Full, stack >> > only, and other distributions like Haskell for Mac) on another page. >> > >> > Since there seems to be confusion about how the committee comes to a >> > consensus I should note that at this point I'm only speaking for myself >> > here. This is just my recommendation, and I'm open and willing to listen >> > to >> > other views before considering what I think is best. I am not usually >> > overtly vocal in these discussions, but I do read what is said and form >> > my >> > own opinions. >> > >> > Best wishes, >> > >> > Nick >> > _______________________________________________ >> > Haskell-community mailing list >> > Haskell-community at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> > >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > From johnw at newartisans.com Thu Sep 1 07:41:50 2016 From: johnw at newartisans.com (John Wiegley) Date: Thu, 01 Sep 2016 00:41:50 -0700 Subject: [Haskell-community] haskell.org download page In-Reply-To: (Gershom B.'s message of "Thu, 1 Sep 2016 03:18:59 -0400") References: Message-ID: >>>>> "GB" == Gershom B writes: GB> I think this is a very good point being made. We should disengangle the GB> installer question from the “getting started” question.  Someone on reddit GB> even proposed having two seperate pages entirely. GB> (Again, I give the caveat I’m speaking just for myself here, and thinking GB> this through as an idea I’d like to hear others’ thoughts on). Yes, I also think this is a great idea! +1 -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From friedrichwiemer at gmail.com Thu Sep 1 09:20:15 2016 From: friedrichwiemer at gmail.com (Friedrich Wiemer) Date: Thu, 1 Sep 2016 11:20:15 +0200 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: +1 from me, too. On 01.09.2016 09:41, John Wiegley wrote: >>>>>> "GB" == Gershom B writes: > > GB> I think this is a very good point being made. We should disengangle the > GB> installer question from the “getting started” question. Someone on reddit > GB> even proposed having two seperate pages entirely. > > GB> (Again, I give the caveat I’m speaking just for myself here, and thinking > GB> this through as an idea I’d like to hear others’ thoughts on). > > Yes, I also think this is a great idea! +1 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ekmett at gmail.com Thu Sep 1 12:13:43 2016 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 1 Sep 2016 08:13:43 -0400 Subject: [Haskell-community] Resignation In-Reply-To: References: Message-ID: Shachaf Ben-Kiki and Gershom Bazerman have acted as backup administrators with Google for the last couple of years. If we manage to get into the Google Summer of Code next year, either one of them could take up the mantle without much hullabaloo. On the other hand, if we have to do a self-funded Summer of Haskell, that would take a pretty actively engaged administrator to go try to drum up funding. I'll talk to the folks on the committee to see how they want to proceed. Now that we don't have to hover over SPI someone outside of the committee running it is pretty viable, especially if we're able to just do GSoC; Ryan does all the hard work on the finance side as treasurer. I was also in the process of trying to raise some funding for Gnome Outreachy and general haskell infrastructure work, so I'll see if I can hand off those leads to the rest of the committee as well. -Edward On Tue, Aug 30, 2016 at 6:39 PM, Simon Peyton Jones wrote: > Edward > > > > Your leadership of the Summer of Haskell has been fantastic. It would not > have happened without you. Thank you so much --- you are a star. > > > > Please do stay with the Core Libraries Committee. A group like that only > functions when it is actively led, to bring discussions to a conclusions > and articulate decisions. Thank you for that too. > > > > Simon > > > > PS: Do you have a successor for Summer of Code? Is there a danger that, > leaderless, it just won’t happen next year? Anyone interested in > volunteering to take up the mantle? > > > > *From:* Haskell-community [mailto:haskell-community-bounces at haskell.org] *On > Behalf Of *Edward Kmett > *Sent:* 29 August 2016 06:43 > *To:* haskell-community at haskell.org > *Subject:* [Haskell-community] Resignation > > > > I'm officially resigning from the haskell.org > > committee effective immediately after the end of the Summer of Haskell. > > To those of you on the committee, I apologize for abandoning you. > > The reason I joined and have remained on the committee for the past > several years is entirely to deal with the needs of the Summer of Code, > both financially and administratively. It has provided me a way to give > back to a community that has been so incredibly good to me. > > When Galois managed our finances, someone had to deal with it. When we > moved into SPI, it ironically started taking more effort. When we formed a > non-profit in December things started looking up in terms of administrative > overhead, but then we crushingly weren't accepted into the program this > year. > > In the wake of that I was somehow able to raise funding and wrangle us > around $40,000 in sponsorship to fund eight students to work on Haskell for > the summer. The outpouring of goodwill there was tangible. Those projects > are wrapping up nicely now. > > This part of my role within the committee has been as life affirming and > wonderful as anything I've ever done. > > However, the job is coming at an ever greater personal cost that I'm > simply unwilling to continue to bear. My wife has come to dread the > "there's someone wrong on the internet" moments, and I've come to realize > it isn't fair to her -- I simply find myself spread too thin. > > I shall continue to serve on the Core Libraries Committee, as I do > continue to care deeply about the structure of the language we all love, if > not so much the tooling around it, and I am willing to put in the time to > on that front where I feel much more strongly about the issues at hand and > have what I hope is a nuanced opinion to offer. Ultimately, the barbs > thrown around, say, during the Foldable/Traversable Proposal, while heated, > never felt personal, merely rational disagreement between well meaning > parties with different priorities. > > I care a great deal about our community; it was ultimately Cale and the > rest of the folks in #haskell channel that lured me in at first, not any of > the technical merits of the language. Those only took hold of me later on, > but without that comfortable environment never would have had a chance to > set. > > I do not care enough about the contents of a web page to let my health, > relationships, productivity and home life suffer further. I hope that by > stepping back I can continue to retain or perhaps regain some of those > friendships that recent events have strained. > > > --Edward Kmett > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Thu Sep 1 12:48:17 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 1 Sep 2016 18:18:17 +0530 Subject: [Haskell-community] haskell.org download page In-Reply-To: References: Message-ID: I started on Haskell last year and I fall in the category of "discovering it by searching on google" and learning it myself, nobody told me about Haskell and I did not even know about it before. Let me share my perspective on this issue. I can vouch for Haskell being a very high barrier to entry for casually interested and even moderately motivated people. In the long battle most people will quit before the finish line. I assume our goal here is to make Haskell popular, successful and influential. I believe it is already highly successful in the academic community and among a relatively small community of self motivated people who are smart enough to see why it is the right choice. What we need is to make it successful among the bulk of the engineering community who usually don't care what language they use. When I mention Haskell to anyone I know of in my engineering circle, they are usually confident that I meant Pascal. I think Haskell deserves a lot better than that. I would strongly argue that we should not target the Haskell landing or first download page for those who already know Haskell, they won't even need it. It is for those who do not know enough and want to learn more. It is for luring and then trapping people. Specifically I would say that this page should not be targeted for students or mentored learners in general. It should be targeted to self learners. If you are a student, learning Haskell as part of a course you would have an expert mentor to tell you what to do. If you are a mentor you should know enough to not need that page and if you do then you are in the self learner category anyway. If you are a self motivated person you would anyway find what you need. We need the website to lure the mass engineering community of casual users or moderately motivated self learners usually looking for a better way to solve some problem. In the engineering community people have little time. Everybody is busy with their day to day work and nobody has time and motivation to put huge amount of time and effort to learn something that they do not even know whether it will be useful. The way we can lure them is by showing how easily they can solve one of their small day to day problem, using Haskell, without investing a huge amount of time. That means we need a _zero_ learning build tool. Though build tool is not the only hurdle but it is an important first step. In my opinion we should not even talk about build tool user guide for beginners, it should not be required, the tool must be intuitive enough and the help available with it must be really good. Once you graduate to advanced usage it is a different matter altogether. Another point that I want to make is that we should list only _one tool_ on the front page. Multiple choice is an immediate psychological barrier for beginners. When the users have a choice they must decide on one out of many. So either you explain the rationale right there or they will have to search the internet for reviews etc. In any case it requires an effort to choose and has a risk of turning them off. The committee should decide on a single choice after gathering enough information on what is best. They can ask for a shootout from the competing tools if that's needed. In my opinion and from my experience learning Haskell for last one year or so, stack is a pretty good choice at the moment. It fits most of the requirements of a tool which has an out of the box experience. Though it may not be perfect it seems to be generally in the right direction especially for those who want to get started quickly and effortlessly. -harendra On 1 September 2016 at 12:39, Gershom B wrote: > I think this is a very good point being made. We should disengangle > the installer question from the “getting started” question. Someone > on reddit even proposed having two seperate pages entirely. > > A getting started page that promoted a stack centric workflow for > beginners as a good “default path” would be reasonable in my eyes, and > certainly worth discussing. Certainly if it let us lay the downloads > page to rest with a single option for a minimal installer (with > perhaps slightly different branding as discussed on a ticket I linked > earlier — “Haskell Toolchain” or the like) that provided ghc, stack > and cabal all, then I think that would be a very good way to go. > > That way Nicolas and others who wanted to direct people to the > downloads page, and then wanted to teach them with one sort of > approach would be able to do so, people who wanted to direct people to > the downloads page, and teach them with a stack-based approach would > be able to do so, and people coming to the site directly could > immediately find a “getting started page” with a single approach that > got them up and running quickly, and that approach could well be > stack-oriented if that’s what people think gives the best experience > for that particular use case. > > (Again, I give the caveat I’m speaking just for myself here, and > thinking this through as an idea I’d like to hear others’ thoughts > on). > > —gershom > > > On August 31, 2016 at 5:48:41 PM, Nicolas Wu (nicolas.wu at gmail.com) wrote: > > Hi Paolo, > > > > On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso > > wrote: > > > > > > The decision about how to manage projects and their dependencies > should > > > be > > > > open and isn't for beginners, whether that be using stack or cabal: > both > > > > have their merits, and I don't want to push one over the other. > > > > > > I'm honestly confused what you're arguing. You say this decision isn't > > > for beginners, yet you propose offering the HP. So how should a > > > beginner install a package without first deciding whether to use > > > cabal-install or stack? Or can a beginner meaningfully be expected to > > > learn using both alternatives? > > > > > > > Sorry for not being clear, my bad. Hopefully I can clarify and elaborate > a > > bit more. > > > > I think a beginner doesn't usually make the choice of how to use > > GHC/stack/cabal by themselves; they are usually being instructed by > someone > > (or a resource) that has decided that for them. On that front I don't > think > > there's a singular best way to approach this; there's diversity in the > way > > people approach teaching and that's fine and healthy, there's also > > diversity in the way people learn and the goals they have with the > language > > and that's fine and healthy too. We should be supporting people who want > to > > learn the language as well as people who want to contribute to teaching. > We > > should respect diversity in those roles; if someone wants their students > to > > use only stack then by all means they can do so, that shouldn't stop > others > > from using ghc or ghci directly. > > > > For instance, if a beginner is just trying to run small examples they see > > on a blog, then maybe all they need is a call to ghci. If they're > learning > > about making a simple binary they might want ghc. If they want to have a > > whole managed project, perhaps they're after either stack or cabal. The > > point is that they're usually guided by something, and those guides do > > differ on what they prefer and recommend. The default download should > > easily support these different modes of learning and teaching. > > > > > > > Also, do both tools have their merits *for beginners*? We're talking > > > of cabal as-is, not of the ongoing work on new-build. > > > > > > > I'm talking about having a default that bundles tools like ghc, cabal, > and > > stack, since these are the main tools our community has for compiling and > > executing Haskell code. I don't want to force people into one of > > these--whether that be students or educators. In all cases the default > > download recommendation should support all of these since they are the > > mainstream tools we use. To avoid confusion I think there should be only > > one recommended option on the main download page (and here the HP minimal > > seems to satisfy this, and stack seems to preclude this). The download > page > > should also have a link to other resources (such as the HP Full, stack > > only, and other distributions like Haskell for Mac) on another page. > > > > Since there seems to be confusion about how the committee comes to a > > consensus I should note that at this point I'm only speaking for myself > > here. This is just my recommendation, and I'm open and willing to listen > to > > other views before considering what I think is best. I am not usually > > overtly vocal in these discussions, but I do read what is said and form > my > > own opinions. > > > > Best wishes, > > > > Nick > > _______________________________________________ > > Haskell-community mailing list > > Haskell-community at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Sep 1 14:23:18 2016 From: gershomb at gmail.com (Gershom B) Date: Thu, 1 Sep 2016 07:23:18 -0700 Subject: [Haskell-community] Bounce rate In-Reply-To: References: Message-ID: On September 1, 2016 at 2:31:33 AM, Tony Day (tonyday567 at gmail.com) wrote: > What might be useful is knowing what the visitor stats are, and the new > visitor bounce rate. We lost a lot of that info because somehow our google analytics account got turned off or we lost access or something. (Anyone have any idea what happened? Please email me if so). I’ve updated us to a new account, but in the meantime there isn’t much data yet. I’d be interested to know what sorts of insights you’re looking for from it. At a high level, “downloads” is the most hit page outside of the front, with “documentation” following, and users often go from there to “downloads”. From the frontpage itself, apparently only about half of users go on to a subsequent page. I confess though, I don’t much know what to do with this sort of information :-) Cheers, Gershom From gershomb at gmail.com Thu Sep 1 21:12:22 2016 From: gershomb at gmail.com (Gershom B) Date: Thu, 1 Sep 2016 17:12:22 -0400 Subject: [Haskell-community] Next Steps in Downloads Page Discussion Message-ID: Hi all. Let me try to sum up the state of the discussion and propose next steps -- please feel free to disagree with my summary if you are so inclined. I'm trying to capture the current state and help move discussion, so if people feel this doesn't capture it, its good to know sooner rather than later. == Key Points == * We distinguish between "download method / installer" and "getting started". We add a new page "Getting Started" with links at the top level just like "Downloads / Community / Documentation / News". * The Downloads page points to the minimal platform installer (however named) that includes GHC, stack, cabal-install, and a few other binaries (but no extra global libraries). Below that we can have links to other mechanisms as well, but the minimal platform is the clearly distinguished recommended way. * The "Getting Started" page proceeds to describe next steps for new users to get up and running right away after installing the minimal platform. Since many people have made the case that for someone who hits the page without some prior guide, a stack workflow is the easiest to get running on and best documented at this time, I imagine this workflow will be stack-oriented. == Additional Considerations == * People have pointed to some issues in the windows platform installer. We are going to work to resolve these. A patch for one (which improves stack behavior when it can find ghc but not msys) is already submitted. Sorting out the other (which pertains to enterprise installs, not single-user installs) is underway. * As in the past, we shouldn't focus our discussions on what the answer is "for all time" -- tech will change, things will evolve. We should think of this as something that does the job reasonably well for say the next six months, give or take. == Next Steps == * There is a mock-up of a new download page already on github (Thanks so much Jacco!): https://github.com/haskell-infra/hl/issues/176 Under its "getting started" I would propose something like: 1. Download and run the Haskell Toolchain installer 2. Follow the _getting_started_guide_ to start running some code! with the latter linking to the new getting started page. I hope this is acceptable to people? Maybe some other bullet points should be there too... * I would like to solicit a kind volunteer or two to draft up what they think a "getting started guide" should look like so we can spawn a separate discussion on that. Given that we've decoupled this guide from the download page, it can afford, I think, to have a bit more text than just how to compile and run "hello world"... == a few other thoughts == We've had a productive discussion on this list, I think. But as many probably know, not all the discussions over this have been so positive. I just want to make a general point that has been nagging at me, and apologies for the sappiness that follows. While there is some commercial support, Haskell is an open-source language and community at heart that historically has and currently still relies on people volunteering their time. Be it in writing code, writing documentation, teaching others, and especially in working on tooling and infrastructure. (This goes all the way up to GHC which also runs on donated time and effort in many ways). Being run on volunteer steam is great in many ways. But it has one important caveat. People have to want to volunteer, because they enjoy the technical challenges, but especially because they want to help others, and because they find it rewarding to contribute to things which bring joy and benefit to others. All of us, working on installers, working on fundraising efforts, working on documentation, working on compilers and libraries, or trying to sort out weird issues with mailservers and proxying content delivery networks or php bugs impacting wikis or google-analytics tokens or whatever else, we're all here not because we have to be, but because we want to be. And that's great! But it is also precarious and fragile, because if it becomes not fun, or not rewarding, or we feel that what we do is being disparaged and attacked (and this goes for everyone, i think, on all sides of recent discussions) or diminished, then we change our calculus, and we stop wanting to participate, and stop wanting to fix things for others. And that's understandable. So, if we let our discussions or language play out in a way that can hurt others, can make them feel that their work is no good, or not appreciated, then they have no reason to want to help anymore. And they won't. And I can't blame them. And if we all start to hurt one another too much, it will become no fun for any of us, and then the whole endeavor falls apart. So I want to extend my gratitude and thanks to everyone working on any element of our open-source tooling and infrastructure, or even lending a voice to give insight into how to improve it. And I also want to ask us all to remember this in our interactions with one another, and to remember that people will say things we find unbelievably wrong at times, and discussions may stall at times, and things may get stuck for longer than we'd like. And we have every right to get frustrated when that happens. But we can't let our frustrations at difficult _situations_ turn into words that diminish other _people_, other potential collaborators, others also freely giving of their time trying to improve and help others, whatever our disagreements. I have more to say, but I'm not sure how, and this is long and inarticulate enough. Anyway, onto the next steps (I hope), and please everyone consider stepping forward to help with this stuff, in drafting language, or helping with design and implementation of the actual changes to the site (on which more volunteers welcome -- please email me!), etc. (By the way I want to put out more calls for help on more concrete infra stuff soon, not at all web related -- but in the immediate future, if you have experience running a mail server and dealing with the many painful hassles therein, and are willing to help a bit, please contact me soon). Best, Gershom From code at funwithsoftware.org Thu Sep 1 23:48:42 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Thu, 1 Sep 2016 16:48:42 -0700 Subject: [Haskell-community] Next Steps in Downloads Page Discussion In-Reply-To: References: Message-ID: On 9/1/16 2:12 PM, Gershom B wrote: > We've had a productive discussion on this list, I think. But as many > probably know, not all the discussions over this have been so > positive. +1 I am really happy about the positive, conciliatory tone the discussion has taken in the past few days. I had been disheartened by the schism that has grown in the Haskell community over the past year or so. As a user, I was especially turned off by packages whose sole description was essentially "go to Stackage if you want to read the description": https://hackage.haskell.org/package/http-conduit-2.2.0.1 I am a happy user of both caball-install and stack, and ideally I'd like to see the two ecosystems work more closely in the future, but at the very least, I'd like to see them coexist peacefully and respectfully, and not have individual packages "take sides." > So I want to extend my gratitude and thanks to everyone working on any > element of our open-source tooling and infrastructure, or even lending > a voice to give insight into how to improve it. In that vein, is there a place to file bugs against HaskellWiki? Or is that one of the areas in need of a volunteer? My own personal itch I'd like to scratch is the lack of diffs on the wiki: https://mail.haskell.org/pipermail/haskell-cafe/2016-April/123701.html Many thanks to the Haskell Committee, to FP Complete, and to all of the volunteers who work on Haskell! --Patrick From gershomb at gmail.com Fri Sep 2 03:11:40 2016 From: gershomb at gmail.com (Gershom B) Date: Thu, 1 Sep 2016 20:11:40 -0700 Subject: [Haskell-community] Haskell Wiki and Infra In-Reply-To: References: Message-ID: (changing the subject line to reflect this thread) On September 1, 2016 at 7:48:46 PM, Patrick Pelletier (code at funwithsoftware.org) wrote: > > In that vein, is there a place to file bugs against HaskellWiki? Or is > that one of the areas in need of a volunteer? My own personal itch I'd > like to scratch is the lack of diffs on the wiki: > > https://mail.haskell.org/pipermail/haskell-cafe/2016-April/123701.html > > Many thanks to the Haskell Committee, to FP Complete, and to all of the > volunteers who work on Haskell! For issues with the haskell wiki as well as all other infrastructure problems in general, the admin at haskell.org mail alias hits a group of infra maintainers. A github tracker that’s more widely advertised as well might not be a bad idea, since its become so standard. Over the years our current infra/ops team has gotten rather busy in other arenas, so we could use volunteers nearly everywhere (anyone with any sysadmin experience, even if just on a personal box, and who feels they’ll have ongoing time to donate, please email me! and again, anyone who can help deal with mail stuff would be especially appreciated at this moment). We keep things humming, but haven’t really freed up the time to tackle much in the way of pushing things forward. But you’re correct that the wiki could absolutely use a volunteer. I made a bit of an effort last year to get things rolling, but it stalled out pretty quickly (https://mail.haskell.org/pipermail/haskell-cafe/2015-April/119219.html). Perhaps the call was too ambitious and people didn’t know where to start. Maybe it just needed more energy and will to drive it than any of us had in supply at the moment. We _did_ get a team of people approving new accounts instead of just one overworked individual. (Thank you to all who have done that and continue to! It irks me that we need such a manual process, but the waves of spam we got before periodically despite our capcha efforts were far worse). I can’t quite infer from your message if you are volunteering yourself. If you are, thank you so much for your offer! Please email me and we’ll coordinate how to get you the right login credentials, etc. Best, Gershom (Note, by the way, those who may be hesitant to volunteer not out of lack of time or desire to help, but out of fear you don’t have enough experience or knowledge — most admin work [to be honest like most programming] isn’t knowing what to do right away, but instead about knowing some desired end goal, and then being willing to wade through a bunch of searching and documentation to come up with a plan, talking it over with folks, perhaps experimenting a bit, and eventually finally knowing what to do. And, of course, knowing which experiments are irreversable and shouldn’t be conducted :-). And the hardest step usually isn’t in fixing any problem,  but in making the mental leap from “this is a problem someone should fix” to “this is a problem I will fix”.) From paolo.giarrusso at uni-tuebingen.de Fri Sep 9 01:54:12 2016 From: paolo.giarrusso at uni-tuebingen.de (Paolo Giarrusso) Date: Fri, 9 Sep 2016 03:54:12 +0200 Subject: [Haskell-community] Next Steps in Downloads Page Discussion In-Reply-To: References: Message-ID: On 2 September 2016 at 01:48, Patrick Pelletier wrote: > On 9/1/16 2:12 PM, Gershom B wrote: >> >> We've had a productive discussion on this list, I think. But as many >> probably know, not all the discussions over this have been so >> positive. > I am really happy about the positive, conciliatory tone the discussion has > taken in the past few days. I had been disheartened by the schism that has > grown in the Haskell community over the past year or so. As a user, I was > especially turned off by packages whose sole description was essentially "go > to Stackage if you want to read the description": > > https://hackage.haskell.org/package/http-conduit-2.2.0.1 One can debate that description, but the issues with docs on hackage have been ongoing for a few years. I'm sure any help would be appreciated. One pointer to get started is https://github.com/haskell/hackage-server/issues/478. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From rae at cs.brynmawr.edu Tue Sep 13 18:58:45 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 13 Sep 2016 14:58:45 -0400 Subject: [Haskell-community] technical thoughts on stack Message-ID: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> 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 From johnw at newartisans.com Tue Sep 13 19:14:39 2016 From: johnw at newartisans.com (John Wiegley) Date: Tue, 13 Sep 2016 12:14:39 -0700 Subject: [Haskell-community] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> (Richard Eisenberg's message of "Tue, 13 Sep 2016 14:58:45 -0400") References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: >>>>> "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. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From rae at cs.brynmawr.edu Tue Sep 13 19:47:14 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 13 Sep 2016 15:47:14 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> 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 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Tue Sep 13 20:00:57 2016 From: johnw at newartisans.com (John Wiegley) Date: Tue, 13 Sep 2016 13:00:57 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> (Richard Eisenberg's message of "Tue, 13 Sep 2016 15:47:14 -0400") References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: >>>>> "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 From p.giarrusso at gmail.com Tue Sep 13 20:01:28 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Tue, 13 Sep 2016 13:01:28 -0700 (PDT) Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Sep 13 20:02:43 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:02:43 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: I almost never (maybe twice in the last year) do this, but when I need an environment that has Stack provided GHC-stuff in the path, I use `stack exec my-shell`. On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery wrote: > > On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg > wrote: >> >> Other minor points: >> `stack env` does not work for me: my version of stack does not know how to >> `env` > > > I think they said that was an add-in. IIRC stack is extensible with external > commands, in roughly the same way git is. > > (I am also not fond of stack, and even less fond of the politics that go > with it, but will stick to the technical here.) > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at 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 From cma at bitemyapp.com Tue Sep 13 20:05:39 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:05:39 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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 From p.giarrusso at gmail.com Tue Sep 13 20:08:58 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Tue, 13 Sep 2016 13:08:58 -0700 (PDT) Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Sep 13 20:10:55 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:10:55 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Chris Allen Currently working on http://haskellbook.com From Sylvester3 at haskell.org Fri Sep 9 16:23:34 2016 From: Sylvester3 at haskell.org (Sylvester) Date: Fri, 09 Sep 2016 18:23:34 +0200 Subject: [Haskell-community] :Documents Requested Message-ID: Dear haskell-community, Please find attached documents as requested. Best Regards, Sylvester -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: new doc(064).zip Type: application/zip Size: 8332 bytes Desc: not available URL: From tanuki at gmail.com Tue Sep 13 19:07:52 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Tue, 13 Sep 2016 12:07:52 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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, 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 13 19:18:51 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 13 Sep 2016 15:18:51 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <20160913191315.hsyeldgtjxavcul4@localhost.localdomain> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20160913191315.hsyeldgtjxavcul4@localhost.localdomain> Message-ID: 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 allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 13 19:20:11 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 13 Sep 2016 15:20:11 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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 allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Tue Sep 13 19:26:38 2016 From: cdsmith at gmail.com (Chris Smith) Date: Tue, 13 Sep 2016 12:26:38 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Tue Sep 13 19:33:56 2016 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue, 13 Sep 2016 21:33:56 +0200 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 13 19:55:53 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 13 Sep 2016 15:55:53 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg wrote: > Other minor points: > `stack env` does not work for me: my version of stack does not know how to > `env` > I think they said that was an add-in. IIRC stack is extensible with external commands, in roughly the same way git is. (I am also not fond of stack, and even less fond of the politics that go with it, but will stick to the technical here.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle at ondy.me Tue Sep 13 19:13:15 2016 From: kyle at ondy.me (Kyle Ondy) Date: Tue, 13 Sep 2016 15:13:15 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <20160913191315.hsyeldgtjxavcul4@localhost.localdomain> On 16-09-13 12:07, Theodore Lief Gannon wrote: > Stack *does* allow direct interaction with GHC: > > stack exec -- ghc version > I find `stack ghc -- --version` to be a bit easier. Anything after the `--` is passed as an argument to ghc. From the help documentation: stack ghc -- X.hs -o x > Granted this lacks a bit in brevity, but if you want to issue multiple > commands from "inside" stack's private environment, you can also just do > this: > > stack exec sh > > On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg > wrote: > > > I’ve watched the recent back-and-forth about stack with quite a bit of > > interest (as many of us have). The discussion inspired me to take another > > look at stack. Here are the results of that foray. > > > > First, a disclosure: While I have appreciated the emergence of a new build > > tool for Haskell, I have never much liked stack. One of my chief goals in > > taking another look is to understand better why I do not like it. > > > > My task: Set up a Haskell environment on a new machine (a Mac). This > > machine has no Haskell infrastructure on it. > > > > My approach: > > > > 1. `brew install haskell-stack`. Success. > > > > At this point, I do not have a Haskell project I wish to build. Instead, I > > really just want the ability to run Haskell expressions in GHCi. So I skip > > `stack new` and go straight to > > > > 2. `stack setup`. This succeeds, but prints out some interesting messages > > along the way, including > > > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > > Right Nothing > > > > At the end, I am helpfully told > > > > > To use this GHC and packages outside of a project, consider using: > > > stack ghc, stack ghci, stack runghc, or stack exec > > > > > > > So I then > > > > 3. `stack ghci`. My computer’s first reaction is to say > > > > > Run from outside a project, using implicit global project config > > > Using resolver: lts-6.17 from implicit global project's config file: > > /home/rae/.stack/global-project/stack.yaml > > > Error parsing targets: The specified targets matched no packages. > > > Perhaps you need to run 'stack init'? > > > Warning: build failed, but optimistically launching GHCi anyway > > > > > > > which doesn’t make me feel all that comfortable, but then I am indeed > > delivered to the GHCi prompt, which works as expected. > > > > Done with GHCi, I quit. I then want to double-check which version of GHC I > > got, so I > > > > 4. `stack ghc --version`. This command reports > > > > > Invalid option `--version’ > > > > Grumble. It seems I can’t interact with GHC directly. > > > > ———— > > > > At this point, I am reminded why I dislike stack: > > > > **It’s optimized for a different workflow than I use.** > > > > And I think this fact (repeated by others’ experiences) is why a segment > > of our community has not celebrated stack as much as other segments have. > > We all have different workflows. > > > > From what I understand about it, stack is great for a project-based > > workflow. In this workflow, you are working on a Haskell project. You are > > happy to specify settings in .cabal and stack.yaml files. And you really > > want your build to work in the future and on other machines. > > > > In my experience, stack is not great with a compiler-based workflow. In > > this workflow, you aren’t quite as organized perhaps and do not have all > > your settings written. You also want the ability just to compile a file > > without changing any configurations. You want to be able to start GHCi with > > a nice set of libraries with which to experiment. > > > > I definitely like a compiler-based workflow. I’m sure that many of you > > prefer a project-based workflow. > > > > The great news here is that we have a choice: use stack for a > > project-based workflow, and don’t use it when you want a compiler-based > > workflow. No one needs to convince others about personal preferences. > > > > But there is one nagging issue: what do we suggest to newcomers? The > > downloads page right now is not serving us well. (I was legitimately > > scratching my head at first trying to figure out how to provision a new > > computer.) Sadly, I don’t see a good option presenting itself. Both > > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > > serious shortcomings. > > > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > > Platform Minimal) does appear to lack a “here’s what you do first” > > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > > discover — you have to choose the oft-maligned Haskell Platform link before > > you are told that there is a minimal variant. > > > > B. stack sets up GHC in a way that either 1) requires a project-based > > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > > warnings every time GHC is invoked outside of a project. Furthermore, stack > > prohibits direct interaction with GHC (as in `ghc --version`). > > > > There’s more good news here! Both of these problems are really easy to fix. > > > > To fix (A), someone just has to write the tutorial. > > > > To fix (B), stack just needs a new option so that `stack setup` installs a > > system GHC. Perhaps it would even be sufficient for `stack setup` to > > clearly tell the user where ghc is installed and what to add to their PATH. > > > > I also think, if readers agree with my conclusions about workflows, we > > should consider writing up criteria that potential users should consider > > when choosing what workflow to start with. We’ll need to have a tighter > > recommendation for those with no experience programming, but most > > developers should be able to recognize what workflow they prefer and choose > > accordingly. > > > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > > we’ll really be in a quandary about which installation procedure to put > > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > > one happens first gets to be featured first on the page? :) > > > > So: Does my characterization of workflows resonate? Have I perhaps > > identified part of the burning black heart of the reason behind the vitriol > > of late? Should we fix (A) and (B)? > > > > I’m looking forward to hearing your thoughts. > > > > Richard > > > > > > -=-=-=-=-=-=-=-=-=-=- > > Richard A. Eisenberg > > Asst. Prof. of Computer Science > > Bryn Mawr College > > Bryn Mawr, PA, USA > > cs.brynmawr.edu/~rae > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From p.giarrusso at gmail.com Tue Sep 13 20:16:59 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Tue, 13 Sep 2016 13:16:59 -0700 (PDT) Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Sep 13 20:27:49 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:27:49 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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 From svenpanne at gmail.com Tue Sep 13 20:24:43 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 13 Sep 2016 22:24:43 +0200 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Tue Sep 13 22:49:39 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 14 Sep 2016 04:19:39 +0530 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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 > > allbery.b at gmail.com > ballbery at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Wed Sep 14 00:06:47 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Tue, 13 Sep 2016 17:06:47 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: <3b24b61c-a41e-83fa-41fb-5b7e314c9101@funwithsoftware.org> 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 From michael at snoyman.com Wed Sep 14 01:39:15 2016 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Sep 2016 01:39:15 +0000 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Sep 14 14:42:50 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 14 Sep 2016 15:42:50 +0100 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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 subscribed via the mailman list are allowed to post. > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed Sep 14 15:23:05 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 10:23:05 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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 >> >> > 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 at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > -- Chris Allen Currently working on http://haskellbook.com From marlowsd at gmail.com Wed Sep 14 15:54:46 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 14 Sep 2016 16:54:46 +0100 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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 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 at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > > > > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Sep 14 15:59:14 2016 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Sep 2016 18:59:14 +0300 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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.giarrusso at 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... at 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://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 at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> > >> > >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Sep 14 14:51:13 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 14 Sep 2016 23:51:13 +0900 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: <1473864646-sup-8826@sabre> 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 From david.feuer at gmail.com Wed Sep 14 17:47:54 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 14 Sep 2016 13:47:54 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: 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.giarrusso at 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... at 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://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 at haskell.org >>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> > >>> > >>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppelleti at funwithsoftware.org Wed Sep 14 19:10:12 2016 From: ppelleti at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 12:10:12 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> 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 From cma at bitemyapp.com Wed Sep 14 19:21:58 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 14:21:58 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Wed Sep 14 19:26:24 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 14:26:24 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> Message-ID: 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 at 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 at 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 From code at funwithsoftware.org Wed Sep 14 19:42:27 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 12:42:27 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> Message-ID: <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> 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 From cma at bitemyapp.com Wed Sep 14 20:10:22 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 15:10:22 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: 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 ( >> 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-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 From code at funwithsoftware.org Wed Sep 14 20:20:59 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 13:20:59 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: <0ad5ef8e-7362-3258-5209-75d69e7d77a7@funwithsoftware.org> 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 From cma at bitemyapp.com Wed Sep 14 20:26:12 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 15:26:12 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <0ad5ef8e-7362-3258-5209-75d69e7d77a7@funwithsoftware.org> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> <0ad5ef8e-7362-3258-5209-75d69e7d77a7@funwithsoftware.org> Message-ID: 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 From harendra.kumar at gmail.com Thu Sep 15 02:46:26 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 15 Sep 2016 08:16:26 +0530 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <1473900137.2517.141.camel@googlemail.com> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: That's good news. I think the community will benefit from a healthy competition among the tools. It is good to have choices in terms of the front end but I would rather prefer a unified specification of configuration. Currently with a stack workflow one has to deal with two config files i.e. stack.yaml and project.cabal. There is no reason why the stack and cabal configs cannot be unified. The concept of frozen snapshots is generic and useful enough to be incorporated as a common specification used by all tools. If there is a unified config then the same package can be used with stack or cabal, with hackage or stackage without any problems, choose what you prefer. Another point that I want to make is that I have found the cabal config files hard to deal with. There are a number of annoying problems with it and it lacks in reuse. That is the reason for tools like hpack ( https://github.com/sol/hpack) to be built to overcome those problems. I think the problems that hpack solves should be natively solved by cabal. I guess these problems are long pending and cabal did not evolve fast enough. That could be one of the reasons for wrappers on top of cabal or competing tools like stack getting created. Are there any thoughts going towards a better config specification? While we are at it it maybe good to have an extensible config which can provide optional tool specific extensions. -harendra On 15 September 2016 at 06:12, Duncan Coutts via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > On Tue, 2016-09-13 at 14:58 -0400, Richard Eisenberg wrote: > > I’ve watched the recent back-and-forth about stack with quite a bit > > of interest (as many of us have). The discussion inspired me to take > > another look at stack. Here are the results of that foray. > > Since this is all being discussed now, it is perhaps worth explaining > what the cabal developers are working on and the direction they're > going. > > The cabal tool is getting a major overhaul. At this point there's a > relatively large group of people who have been "dogfooding" it in their > normal daily work for months (and for a few brave users since the > beginning of the year). > > There is a tech preview of this in the 1.24 release. The latest git > version has a user guide which explains things in more detail, and what > you can expect to work already and what is known to be incomplete > (including several temporary workarounds for missing features). > > https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html > > What is broadly the same is that it still supports the "library solver- > based, work with my current ghc / environment" style that people have > mentioned in this thread. For example by default it picks up the ghc on > your path (and will automagically do the right thing if you change your > path). > > That said, the intention is also to better support a "application > frozen / package collection" style, which is the style that stack > supports well currently. > > What is new is that it does what it does a whole lot better, more > conveniently, more predictably. There's a lot fewer cases where you > have to use multiple commands to do various steps. Much of the time you > can simply ask to build/repl something, and everything else is > automatic (and quick to not do much if not much changed). It's more > predictable in that it's much more deterministic. The choices about > what versions etc are picked depend only on your environment (e.g. ghc > version), hackage snapshot and local explicit project state. In > particular it does not matter what you installed previously. (To > support the application/frozen workflows these aspects of the > environment can all be captured and frozen in a project file.) > > It also avoids the "cabal hell" issues of clashing installed versions. > Or to put it another way, it's a bit like sandboxing but without the > mental overhead or the waiting around for everything to build (because > there's automatic maximal sharing of built packages, a la nix). > > It *is* project based, but a minimal project can actually be implicit, > and most projects don't need to specify anything more than a list (or > glob) of the directories of the packages in the project. > > One of the things you were mentioning was how nice it is to just be > able to run ghc or ghci on a source file, or even without any file, > just to play around. A feature that will be landing soon in cabal- > install head is the ability to simply run ghc/ghci within a cabal > project directory and ghc will start up in the environment of the > project. No extra wrapper scripts, shell sessions or env vars > necessary. > > So the short term goal is to get all this to the stage where it can > replace the default UI in the cabal tool, and thereafter one goal is to > better support the workflow style that stack currently supports well, > ie applications with frozen / carefully change-controlled environment, > and package collections/snapshots chosen by 3rd parties. > > I should also say that any help is most welcome. Development takes > place on github. We now have several active reviewers so review & > feedback on contributions is very quick. It's not all just hard > problems, there's plenty to do for newcommers too (e.g. write that > tutorial!). There's an active #hackage IRC channel. Newcommers are > always welcome. > > Duncan > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.coutts at googlemail.com Thu Sep 15 00:42:17 2016 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu, 15 Sep 2016 01:42:17 +0100 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <1473900137.2517.141.camel@googlemail.com> 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 From code at funwithsoftware.org Thu Sep 15 06:06:29 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 23:06:29 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: 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 From harendra.kumar at gmail.com Thu Sep 15 07:32:50 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 15 Sep 2016 13:02:50 +0530 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.coutts at googlemail.com Thu Sep 15 10:28:27 2016 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu, 15 Sep 2016 11:28:27 +0100 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: <1473935307.2517.161.camel@googlemail.com> 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 From ezyang at mit.edu Thu Sep 15 14:23:41 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 15 Sep 2016 23:23:41 +0900 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: <1473949231-sup-150@sabre> 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 From harendra.kumar at gmail.com Thu Sep 15 23:19:05 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 04:49:05 +0530 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <1473949231-sup-150@sabre> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Sep 15 23:24:52 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 15 Sep 2016 19:24:52 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: 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 allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Thu Sep 15 23:31:37 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 05:01:37 +0530 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Thu Sep 15 23:42:16 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Thu, 15 Sep 2016 16:42:16 -0700 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Sep 15 23:55:17 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 16 Sep 2016 08:55:17 +0900 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: <1473982629-sup-5966@sabre> > 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 From cma at bitemyapp.com Fri Sep 16 00:19:16 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 15 Sep 2016 19:19:16 -0500 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <1473982629-sup-5966@sabre> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -- Chris Allen Currently working on http://haskellbook.com From ezyang at mit.edu Fri Sep 16 02:23:56 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 16 Sep 2016 11:23:56 +0900 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: 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 at 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. From spam at scientician.net Fri Sep 16 02:49:01 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 16 Sep 2016 04:49:01 +0200 Subject: [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: On 2016-09-16 02:19, Christopher Allen wrote: > The YAML parser backing hpack and Stack supports a subset of yaml, so > the complexity isn't there. As I understand it, the point of using YAML in this case isn't that "there's a library for that". It's that it's *standard* such that other tools can read/write it and know for certain that what gets read/written is at the very least 'syntactically' correct. As such, using some nebulous "subset of yaml" defined by an implementation[1] doesn't really make sense for interop purposes. (I'm honestly not sure how many *actually* fully conforming YAML parsers there are out there, but I'd place my bets of "not many" given the complexity of the spec. See http://yaml.org/spec/1.2/spec.html ) > TOML isn't supported because a well-supported/known-good library > wasn't to hand, whereas the yaml one did. I don't think people would > mind changing over, but somebody has to do the work validating that > the one-still-maintained-of-two-libraries TOML library is suitable. Even though there are probably fewer implementations, TOML is aiming[2] to become a standard format, so it's (hopefully going to be) a standard and a much simpler one than YAML. That'll hopefully lead to more implementations over time, but who knows? It's *also* simple enough that implementing a fully conforming parser/writer is probably a few days' work, if that. That means that any tools that cannot use an existing library (for whatever reason) actually have a shot in hell of implementing TOML support themselves. That is not the case for YAML -- witnessed by the number of yaml libaries that are actually just bindings for C-based yaml libraries. (I have other issues with TOML, but that's a different matter. The major sticking point for me would be the lack of *clean* support for nesting without the order-dependence, but that may not matter much for Cabal.) > > Keep in mind while discussing all this that Cabal's own solver doesn't > actually live outside of cabal-install. FWIW, this seems mostly like a historical accident more than anything else and at this point it's a *very* non-trivial undertaking to fully separate it out, though there have been steps in this direction. I don't see it happening unless the parties who are actually interested in *using* it outside of cabal-install do the majority of the work. > Contributing to the Cabal project itself is a gauntlet run, which > is partly why many of these > projects spawned outside of it. Further, Cabal itself can't really > grow any dependencies because of the bootstrap problem. > > Nobody wants to shim / inline all the dependencies that enable the > devs to work efficiently into Cabal and such a PR would never get > merged anyway. You're right that Cabal-the-library is generally a very difficult thing to change (due to sheer inertia and stability guarantees), but -- as Patrick Pelletier points out -- implementing a new file format shouldn't matter for consumers of Cabal as long as Cabal emits the old standard Cabal configuration data structures. Meanwhile, it would open up the possibility of non-Cabal-based programs understanding and writing .cabal files (up to semantics defined by documentation). I'm not sure how much that benefit that would confer, but given that Cabal's parser is already a mess[3] with loads of corner cases I'd say it's probably worth it *just* from a software engineering perspective to get the basic syntax parsing disconnected from Cabal and to get rid of the old code. Btw, Cabal/cabal-install development has opened up and picked up pace considerably in the last year or two, you might want to reconsider automatically concluding that such-and-such PR "[...] would never get merged anyway". Anyway, this sub-thread is probably veering too off-topic, so I'll stop there. Regards, /b Notes: [1] At least, from a quick skim of the available documentation at https://hackage.haskell.org/package/yaml I wasn't able deduce what subset of YAML was supposed to be supported. Maybe I just missed it. [2] As of now the README for the current v0.4.0 spec says: "Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly.". I guess one can pin to 0.4.0. [3] Work to at least replace it with a parsec-based implementation has been happening here, but the amount of work in https://github.com/haskell/cabal/pull/3602 seems indicative of a *lot* of complexity. (Granted it's hard to tell exactly how much of that complexity is due to mapping to Cabal's data structure vs. just the "parse into a KV-map" bits.) From harendra.kumar at gmail.com Fri Sep 16 06:20:15 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 11:50:15 +0530 Subject: [Haskell-community] Standard package file format Message-ID: I am starting a new thread for the package file format related discussion. >From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways. Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem. I gather the following from the discussion till now: * We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools. * cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it. * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A significant chunk of developer community is already familiar with it. It is being used by stack and by hpack as an alternative to cabal format. The complaint against it is that the specification/implementation is overly complex. * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption. As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files. More thoughts, opinions on the topic will help create a better understanding about it. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 07:05:37 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 09:05:37 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Why not adopt (a subset of) .hs AST file format to structure both project and package files? This would simplify parsing config files as well as syncing code and config files in IDEs. To draw an analogy, JSON derives from JavaScript. Isn't this a precedent? ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Sep 16 07:18:29 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 12:48:29 +0530 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: On 16 September 2016 at 12:35, Imants Cekusins wrote: > Why not adopt (a subset of) .hs AST file format to structure both project > and package files? > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Sep 16 07:22:44 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 16 Sep 2016 09:22:44 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it. So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file. Alan On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar wrote: > On 16 September 2016 at 12:35, Imants Cekusins wrote: > >> Why not adopt (a subset of) .hs AST file format to structure both project >> and package files? >> > > Aha, that's my preferred choice. If there is a way to restrict features > and we can allow just a subset we can have a nice configuration language > which is a real language. In fact, I have been toying around this. If we > have to express not just a package specification but a sophisticated build > configuration, we need a real language. Expressing conditionals, reuse etc > becomes a compromise in a purely declarative language. > > For example make has so many built-in functions in it that it has become a > full fledged language by itself. The google bazel build uses python as the > build config language. Haskell will make a much better choice for such use > cases. Pure declarative is a pain for such use cases. > > -harendra > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Fri Sep 16 07:50:43 2016 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 16 Sep 2016 10:50:43 +0300 Subject: [Haskell-community] Coordinating Hackage mirroring procedures Message-ID: Hi all, Duncan, Herbert and I have been having a conversation the past few days about Hackage mirrors, kicked off by [1]. I requested we move the discussion to a public list in case others have some thoughts on what we're discussing. I'll do my best to summarize where we're at and what we're thinking of doing. Duncan and Herbert: please jump in and correct any mistakes :) * Upstream Hackage is hosted on a private IP address which is pointed at by a CDN. Currently, the connection between the CDN and Hackage is over plaintext HTTP, though that might switch to HTTPS soon. * Content on Hackage is secured via hackage-security, so users of cabal-install 1.24 are downloading data securely from the CDN. * There are three different Hackage mirroring tools available: * The original hackage-mirror tool in the Hackage repo itself, used during the migration from Hackage 1 to Hackage 2. It is not hackage-security aware * The hackage-mirror package on Hackage, which uploads to AWS S3. This is what hackage.fpcomplete.com uses, and feeds into Stack. It is also not hackage-security aware. * Herbert's hackage-mirror-tool, which uploads to Dreamhost S3, and ostensibly supports AWS S3 as well (though not yet tested). It _is_ hackage-security aware. * We don't really want three different tools, and we _do_ want the mirror tools to be hackage-security aware, especially given the lack of SSL between the CDN and Hackage itself. * The CDN has the potential to serve out-of-sync files, in particular deliver a 00-index.tar.gz file that refers to a certain package/version, but will return a 404 for the package tarball. This can cause confusion for downstream tools. The Dreamhost and AWS mirrors do not suffer from this. * There are three additional Git repositories providing Hackage metadata in different formats: all-cabal-files, all-cabal-hashes, and all-cabal-metadata. These are used by Stack, Stackage, Nix, and stackage.org. They feed off of the AWS S3 mirror. I believe the course of action we have planned is: 1. Ensure that Herbert's hackage-mirror-tool works correctly with AWS S3. 2. Switch over the hackage.fpcomplete.com AWS S3 mirror to use Herbert's hackage-mirror-tool, increasing its security, and allowing it to be listed as an official Hackage mirror. * This mirror will still be operated by FP Complete, making it less likely that a technical screw-up by one party will take down multiple mirrors by distributing the administration of systems. 3. Continue pointing all-cabal-files, -hashes, and -metadata at the AWS S3 mirror, which provides high reliability and will now be more secure based on the hackage-mirror-tool usage. This will scratch a few different itches: * A new mirror will be available on Hackage for cabal-install users * The AWS S3 mirror will be more secure * I can simplify some of my mirroring logic by not having to do workarounds for out-of-sync CDNs I think this is all doable, and pretty much within reach. I just wanted to get this out in the public first in case others have input, perhaps based on other use cases of these mirrors or repos that I'm not aware of. Michael [1] https://github.com/haskell/hackage-server/issues/537 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 08:23:06 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 10:23:06 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> References: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> Message-ID: > So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, ... ​ well config files could use different (not .hs) extensions. They could use their own Prelude and not allow importing other modules. The main benefit is to reuse existing parsers and simplify code-config sync. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Fri Sep 16 08:24:41 2016 From: cdsmith at gmail.com (Chris Smith) Date: Fri, 16 Sep 2016 01:24:41 -0700 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: I guess the overriding question I have here is: what is the PROBLEM being solved? I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format. It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc. But the syntax? It's just not an issue. I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment. With this in mind, a lot of the statements about these various languages are not entirely convincing. That it's a superset of JSON? It's not clear why this matters. A psychological impression of complexity? Just not anything I've seen evidence of. Indeed, aside from the rather painful many-years-long migration, the *cost* (though certainly not a prohibitive one) of moving to something like YAML or TOML is that they have a bit louder syntax, that demands more attention and feels more complex. There is one substantial disadvantage I'd point out to the Cabal file format as it stands, and that's that it's pretty non-obvious how to parse it, so we will always struggle to interact with it from automated tools, unless those tools are also written in Haskell and can use the Cabal library. That's a real concern; pragmatic large-scale build environments are not tied to specific languages, and include a variety of ad-hoc third-party tooling that needs to be integrated, and Cabal remains opaque to them. But that doesn't seem to be what's motivating this conversation. On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar wrote: > I am starting a new thread for the package file format related discussion. > > From a developer's perspective, the major benefit of a standard and widely > adopted format and is that people can utilize their knowledge acquired from > elsewhere, they do not have to go through and learn differently looking and > incomplete documentation of different tools. The benefit of a common config > specification is that developers can choose tools freely without worrying > about learning the same concepts presented in different ways. > > Multiple formats flying around also create a psychological impression of > complexity in the ecosystem for newcomers. If we have consistency there are > better chances of attracting more people to the language ecosystem. > > I gather the following from the discussion till now: > > * We have cabal, YAML and TOML as potential candidates for a common > package format which can additionally incorporate the concept of > snapshots/package collections and potentially more extensions useful across > build tools. > > * cabal has the benefit of incumbency and backward compatibility, it has > shortcomings which are being addressed but it is still a format which is > very specific to Haskell ecosystem. It is not a standard and not going to > become one. We have to always deal with it ourselves and everyone coming to > Haskell will have to learn it. > > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. > > * TOML (https://github.com/toml-lang/toml) is promising, simpler than > YAML and is being used by a few important projects but is still evolving > and is not completely stable. On a first glance it looks pretty simple and > a lot of other tools use a similar config format. It is aiming to become a > standard and aiming for a wider adoption. > > As a next step we can perhaps do an hpack like experiment using the TOML > format. That way we will have some experience with that as well and get to > know if there are any potential problems expressing the existing cabal > files. > > More thoughts, opinions on the topic will help create a better > understanding about it. > > -harendra > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 08:37:23 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 10:37:23 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: > what is the PROBLEM being solved? by making config files follow .hs syntax, cabal file structure may be defined as a data record. This would make it clear, which fields are compulsory, which are optional. Enums may be used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Sep 16 08:45:47 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 14:15:47 +0530 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: The discussion originated in an earlier thread from a question about the possibility of using the same format across different tools, cabal and stack which currently use different file formats. If they have to use the same format what that format should be. On 16 September 2016 at 13:54, Chris Smith wrote: > I guess the overriding question I have here is: what is the PROBLEM being > solved? I know of basically no beginners who were confused or intimidated > by the syntax of Cabal's file format. It's fairly commonplace for > beginners to be confused by the *semantics*: which fields are needed and > what they mean, how package version bounds work, what flags are and how > they interact with dependencies, the relationship between libraries and > executables defined in the same file, etc. But the syntax? It's just not > an issue. I'm not sure what it means to say that people have to "learn" > it, because in introducing dozens of people to building things in Haskell, > I've never seen that learning process even be noticeable, much less an > impediment. > > With this in mind, a lot of the statements about these various languages > are not entirely convincing. That it's a superset of JSON? It's not clear > why this matters. A psychological impression of complexity? Just not > anything I've seen evidence of. Indeed, aside from the rather painful > many-years-long migration, the *cost* (though certainly not a prohibitive > one) of moving to something like YAML or TOML is that they have a bit > louder syntax, that demands more attention and feels more complex. > > There is one substantial disadvantage I'd point out to the Cabal file > format as it stands, and that's that it's pretty non-obvious how to parse > it, so we will always struggle to interact with it from automated tools, > unless those tools are also written in Haskell and can use the Cabal > library. That's a real concern; pragmatic large-scale build environments > are not tied to specific languages, and include a variety of ad-hoc > third-party tooling that needs to be integrated, and Cabal remains opaque > to them. But that doesn't seem to be what's motivating this conversation. > > On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar > wrote: > >> I am starting a new thread for the package file format related discussion. >> >> From a developer's perspective, the major benefit of a standard and >> widely adopted format and is that people can utilize their knowledge >> acquired from elsewhere, they do not have to go through and learn >> differently looking and incomplete documentation of different tools. The >> benefit of a common config specification is that developers can choose >> tools freely without worrying about learning the same concepts presented in >> different ways. >> >> Multiple formats flying around also create a psychological impression of >> complexity in the ecosystem for newcomers. If we have consistency there are >> better chances of attracting more people to the language ecosystem. >> >> I gather the following from the discussion till now: >> >> * We have cabal, YAML and TOML as potential candidates for a common >> package format which can additionally incorporate the concept of >> snapshots/package collections and potentially more extensions useful across >> build tools. >> >> * cabal has the benefit of incumbency and backward compatibility, it has >> shortcomings which are being addressed but it is still a format which is >> very specific to Haskell ecosystem. It is not a standard and not going to >> become one. We have to always deal with it ourselves and everyone coming to >> Haskell will have to learn it. >> >> * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A >> significant chunk of developer community is already familiar with it. It is >> being used by stack and by hpack as an alternative to cabal format. The >> complaint against it is that the specification/implementation is overly >> complex. >> >> * TOML (https://github.com/toml-lang/toml) is promising, simpler than >> YAML and is being used by a few important projects but is still evolving >> and is not completely stable. On a first glance it looks pretty simple and >> a lot of other tools use a similar config format. It is aiming to become a >> standard and aiming for a wider adoption. >> >> As a next step we can perhaps do an hpack like experiment using the TOML >> format. That way we will have some experience with that as well and get to >> know if there are any potential problems expressing the existing cabal >> files. >> >> More thoughts, opinions on the topic will help create a better >> understanding about it. >> >> -harendra >> >> _______________________________________________ >> 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann.esposito at gmail.com Fri Sep 16 08:57:29 2016 From: yann.esposito at gmail.com (yogsototh) Date: Fri, 16 Sep 2016 01:57:29 -0700 (PDT) Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: > I guess the overriding question I have here is: what is the PROBLEM being > solved? > Let me share my experience with Clojure and lein. They use a clojure hash-map for their configuration. So yes arbitrary code could be executed and I believe this is a _very good thing_. Why? Because it makes it very easy to add sub-configuration that can be used by third party plugin. For example: - a plugin that help the use of environment variables (lein-environ) which is really helpful for application development (not so much for library development) - a plugin that use S3 for our private dependencies (not supported by default by lein) For deployment: we were able to add request to our API server that provide not only the written version but also the git commit hash. So we could be certain of the version of the server. Too much time there were sys/admin deployment errors. And that could only be achieved because we were able to run arbitrary command in the project description file. I certainly forget many other advantages of having a package description format which is simply a data structure in the hosted language. But this has by far my preference. - cabal is ok, but very imperfect, I generally need to have a lot of copy/paste, I need to change it very often while writing application with many dependencies - JSON/YAML/TOML are simply not powerful enough to match all semantics we might need to configure a project. For example we might want to have Set instead of List for some properties. Or I don't know maybe ternary tree structures. The point is: we pay a price by adding a step between the semantic and the syntax. While if our configuration format was in Haskell we could express the semantic more directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 09:15:57 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 11:15:57 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: .. for interop with other packagers / builders, .hs compatible config content could be transformed / exported to other formats. .hs -> YAML, JSON, ... is likely to be possible and easier than the other way around. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Fri Sep 16 09:36:38 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 11:36:38 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format Message-ID: (Resending from right address) We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh wrote: > >> I guess the overriding question I have here is: what is the PROBLEM being >> solved? > > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be used > by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this has > by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From imantc at gmail.com Fri Sep 16 09:49:56 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 11:49:56 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: this may be one of the 3 points on Paolo's list. In case it is not, here is another option (4?): - define .hs data records for project config, package configs - write export tools to export config records to existing formats: cabal stack yaml ... ​ this way, there is no need to revise the current workflow or modify tools. However we define a common standard content structure, most users do not need to worry about .cabal, .yaml syntax -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppelleti at funwithsoftware.org Fri Sep 16 10:13:29 2016 From: ppelleti at funwithsoftware.org (Patrick Pelletier) Date: Fri, 16 Sep 2016 03:13:29 -0700 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> On 9/16/16 2:36 AM, Paolo Giarrusso wrote: > (Resending from right address) > > We're talking about *three* options: > 1. syntax for pure Haskell values, which I'll call HSON (Haskell > jSON). That's just an alternative to YAML/TOML/... That would need > extensions to allow omitting optional fields entirely. > 2. a pure Haskell embedded domain-specific language (EDSL) that simply > generates cabal description records (GenericPackageDescription > values). That would allow abstraction over some patterns but not much > more. But that alone is already an argument for EDSLs—the one Harendra > already presented. > 3. a Haskell embedded domain-specific language (EDSL) designed for an > extensible build tool, like Clojure's (apparently), SBT for Scala or > many others. That would potentially be a rabbit hole leading to a > rather *different* tool—with a different package format to boot. That > can't work as long as all libraries have to be built using the same > tool. But stack and cabal are really about how to manage package > databases/GHC/external environments, while extensible build tools are > about (a more powerful form) of writing custom setup scripts. I > suspect some extensions might be easier if more of the actual building > was done by the setup script, but I'm not sure. Options 2 and 3 both require running Haskell code at build time. This presents problems in a couple of cases: Cross compilation: There are already a couple of cases where we need to run Haskell code at build time: Template Haskell, and custom Setup.hs. Neither of these are supported in cross-compilation. (The former is a ghc issue, while the latter is a Cabal issue.) So I'm assuming that the new Haskell-based EDSL wouldn't work in cross-compilation, either. The difference is that Template Haskell and custom Setup.hs are only used by some packages. But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. Platforms without ghci: Even when not cross-compiling, some platforms don't support ghci. (This is usually the less popular platforms. Not too long ago, it even included ARM.) ghci support is necessary for Template Haskell, and I assume the EDSL would work the same way. So then less popular platforms would be left out in the cold. --Patrick From p.giarrusso at gmail.com Fri Sep 16 10:38:18 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 12:38:18 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: On 16 September 2016 at 12:13, Patrick Pelletier wrote: > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> (Resending from right address) >> >> We're talking about *three* options: >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> jSON). That's just an alternative to YAML/TOML/... That would need >> extensions to allow omitting optional fields entirely. >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> generates cabal description records (GenericPackageDescription >> values). That would allow abstraction over some patterns but not much >> more. But that alone is already an argument for EDSLs—the one Harendra >> already presented. >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> many others. That would potentially be a rabbit hole leading to a >> rather *different* tool—with a different package format to boot. That >> can't work as long as all libraries have to be built using the same >> tool. But stack and cabal are really about how to manage package >> databases/GHC/external environments, while extensible build tools are >> about (a more powerful form) of writing custom setup scripts. I >> suspect some extensions might be easier if more of the actual building >> was done by the setup script, but I'm not sure. > > > Options 2 and 3 both require running Haskell code at build time. > But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. "All packages migrate to new format" doesn't seem really a plausible option, as I already hinted in the text you quote. There are multiple JVM build tools because they're interoperable (like cabal-install and Stack): each library picks its own build tool, but they can still be linked together. Hpack generates cabal files, stack reuses cabal or hpack files. In principle, option 2 just needs a non-cross-compiled program to produce a package description—say by producing a cabal file. You just need to runghc it, either via ghci or by compiling and running a binary. Option 3 can be trickier depending on details, but the as long as you account for cross-compilation in the design it should be doable. For Template Haskell the problem is deeper (see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/), so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From harendra.kumar at gmail.com Fri Sep 16 11:05:44 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 16:35:44 +0530 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: This seems to have gone into a different direction. The original point was about the package specification format and not expressing a full fledged build system. That is an entirely different ballgame. The main point of the thread was whether it makes sense to use a single specification format for both stack and cabal install (YAML vs .cabal and then TOML came into picture). Haskell does not seem to be a choice for a package specification format unless we have a very different goal in mind. -harendra On 16 September 2016 at 16:08, Paolo Giarrusso wrote: > On 16 September 2016 at 12:13, Patrick Pelletier > wrote: > > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: > >> > >> (Resending from right address) > >> > >> We're talking about *three* options: > >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell > >> jSON). That's just an alternative to YAML/TOML/... That would need > >> extensions to allow omitting optional fields entirely. > >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply > >> generates cabal description records (GenericPackageDescription > >> values). That would allow abstraction over some patterns but not much > >> more. But that alone is already an argument for EDSLs—the one Harendra > >> already presented. > >> 3. a Haskell embedded domain-specific language (EDSL) designed for an > >> extensible build tool, like Clojure's (apparently), SBT for Scala or > >> many others. That would potentially be a rabbit hole leading to a > >> rather *different* tool—with a different package format to boot. That > >> can't work as long as all libraries have to be built using the same > >> tool. But stack and cabal are really about how to manage package > >> databases/GHC/external environments, while extensible build tools are > >> about (a more powerful form) of writing custom setup scripts. I > >> suspect some extensions might be easier if more of the actual building > >> was done by the setup script, but I'm not sure. > > > > > > Options 2 and 3 both require running Haskell code at build time. > > > But if all packages had to use the new EDSL, then cross-compilation > would essentially become impossible. > > "All packages migrate to new format" doesn't seem really a plausible > option, as I already hinted in the text you quote. > There are multiple JVM build tools because they're interoperable (like > cabal-install and Stack): each library picks its own build tool, but > they can still be linked together. > Hpack generates cabal files, stack reuses cabal or hpack files. > > In principle, option 2 just needs a non-cross-compiled program to > produce a package description—say by producing a cabal file. You just > need to runghc it, either via ghci or by compiling and running a > binary. Option 3 can be trickier depending on details, but the as long > as you account for cross-compilation in the design it should be > doable. For Template Haskell the problem is deeper (see > http://blog.ezyang.com/2016/07/what-template-haskell-gets- > wrong-and-racket-gets-right/), > so let's *not* use it here. > -- > Paolo G. Giarrusso - Ph.D. Student, Tübingen University > http://ps.informatik.uni-tuebingen.de/team/giarrusso/ > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Fri Sep 16 11:21:40 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 13:21:40 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: On 16 September 2016 at 13:05, Harendra Kumar wrote: > This seems to have gone into a different direction. The original point was > about the package specification format and not expressing a full fledged > build system. That is an entirely different ballgame. The main point of the > thread was whether it makes sense to use a single specification format for > both stack and cabal install (YAML vs .cabal and then TOML came into > picture). Haskell does not seem to be a choice for a package specification > format unless we have a very different goal in mind. I agree "full-fledged build system" is not a possible immediate goal. But an EDSL for expressing cabal projects (as they are today) would still be in scope of your proposal—and I thought you liked the idea (see quote below). Using the earlier options: option 3 is not in scope of this thread, but option 2 is, with the only danger that the design space is so big to present a challenge. Quoting from Harendra Kumar's earlier mail: >> Why not adopt (a subset of) .hs AST file format to structure both project and package files? > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. > For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. > On 16 September 2016 at 16:08, Paolo Giarrusso > wrote: >> >> On 16 September 2016 at 12:13, Patrick Pelletier >> wrote: >> > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> We're talking about *three* options: >> >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> >> jSON). That's just an alternative to YAML/TOML/... That would need >> >> extensions to allow omitting optional fields entirely. >> >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> >> generates cabal description records (GenericPackageDescription >> >> values). That would allow abstraction over some patterns but not much >> >> more. But that alone is already an argument for EDSLs—the one Harendra >> >> already presented. >> >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> >> many others. That would potentially be a rabbit hole leading to a >> >> rather *different* tool—with a different package format to boot. That >> >> can't work as long as all libraries have to be built using the same >> >> tool. But stack and cabal are really about how to manage package >> >> databases/GHC/external environments, while extensible build tools are >> >> about (a more powerful form) of writing custom setup scripts. I >> >> suspect some extensions might be easier if more of the actual building >> >> was done by the setup script, but I'm not sure. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From harendra.kumar at gmail.com Fri Sep 16 11:46:12 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 17:16:12 +0530 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: On 16 September 2016 at 16:51, Paolo Giarrusso wrote: > > I agree "full-fledged build system" is not a possible immediate goal. > But an EDSL for expressing cabal projects (as they are today) would > still be in scope of your proposal—and I thought you liked the idea > (see quote below). Using the earlier options: option 3 is not in scope > of this thread, but option 2 is, with the only danger that the design > space is so big to present a challenge. > Yeah I like the idea of using Haskell for configs but perhaps in a different problem space e.g. in a build spec. See the quote from my earlier quote below, sorry for the confusion :-) Yes, maybe option 2 might work for package specifications but sounds pretty hairy to explore for this use case alone, unless we have other motivations. > Quoting from Harendra Kumar's earlier mail: > > If we have to express not just a package specification but a > sophisticated build configuration, we need a real language. Expressing > conditionals, reuse etc becomes a compromise in a purely declarative > language. > -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdammers at gmail.com Fri Sep 16 06:37:34 2016 From: tdammers at gmail.com (Tobias Dammers) Date: Fri, 16 Sep 2016 08:37:34 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Another factor in favor of YAML is that it is a superset of JSON, which eases the learning curve even more (with JSON being a de facto lingua franca for cross-platform untyped data structures), and offers some extra possibilities, although I admit that I can't think of any practical uses. The fact that both Yaml and JSON can be represented as Aeson Values would also make things (arguably) easier for tool writers. On Sep 16, 2016 8:20 AM, "Harendra Kumar" wrote: > I am starting a new thread for the package file format related discussion. > > From a developer's perspective, the major benefit of a standard and widely > adopted format and is that people can utilize their knowledge acquired from > elsewhere, they do not have to go through and learn differently looking and > incomplete documentation of different tools. The benefit of a common config > specification is that developers can choose tools freely without worrying > about learning the same concepts presented in different ways. > > Multiple formats flying around also create a psychological impression of > complexity in the ecosystem for newcomers. If we have consistency there are > better chances of attracting more people to the language ecosystem. > > I gather the following from the discussion till now: > > * We have cabal, YAML and TOML as potential candidates for a common > package format which can additionally incorporate the concept of > snapshots/package collections and potentially more extensions useful across > build tools. > > * cabal has the benefit of incumbency and backward compatibility, it has > shortcomings which are being addressed but it is still a format which is > very specific to Haskell ecosystem. It is not a standard and not going to > become one. We have to always deal with it ourselves and everyone coming to > Haskell will have to learn it. > > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. > > * TOML (https://github.com/toml-lang/toml) is promising, simpler than > YAML and is being used by a few important projects but is still evolving > and is not completely stable. On a first glance it looks pretty simple and > a lot of other tools use a similar config format. It is aiming to become a > standard and aiming for a wider adoption. > > As a next step we can perhaps do an hpack like experiment using the TOML > format. That way we will have some experience with that as well and get to > know if there are any potential problems expressing the existing cabal > files. > > More thoughts, opinions on the topic will help create a better > understanding about it. > > -harendra > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Fri Sep 16 07:30:44 2016 From: miguelimo38 at yandex.ru (MigMit) Date: Fri, 16 Sep 2016 09:30:44 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> Sbt seems to be doing rather well, using full Scala in configurations. I think package descriptions should be limited, but not syntactically. Using some specific monad might work OK. > On 16 Sep 2016, at 09:22, Alan & Kim Zimmerman wrote: > > The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it. > > So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file. > > Alan > > On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar wrote: > On 16 September 2016 at 12:35, Imants Cekusins wrote: > Why not adopt (a subset of) .hs AST file format to structure both project and package files? > > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. > > For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. > > -harendra > > _______________________________________________ > 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. From paolo.giarrusso at uni-tuebingen.de Fri Sep 16 09:34:59 2016 From: paolo.giarrusso at uni-tuebingen.de (Paolo Giarrusso) Date: Fri, 16 Sep 2016 11:34:59 +0200 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh wrote: > >> I guess the overriding question I have here is: what is the PROBLEM being >> solved? > > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be used > by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this has > by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From Andrew.Butterfield at scss.tcd.ie Fri Sep 16 08:59:48 2016 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Fri, 16 Sep 2016 09:59:48 +0100 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <33096B3E-54BA-4DD9-B03E-C8817333413D@scss.tcd.ie> > On 16 Sep 2016, at 09:24, Chris Smith wrote: > > I guess the overriding question I have here is: what is the PROBLEM being solved? I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format. As a "beginner"(*), I fully agree. However having more than one language in the mix can be confusing and complicating... > It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc. It's all about the semantics - it should preferably be formalised, and ideally the relevant library/package system should be able to check/enforce rules. > But the syntax? It's just not an issue. I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment. I quite agree > Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland (*) I've only started to use cabal recently, because a TA of mine built a cabal-based coursework grading system for me - I generally do application devpt in Haskell and the only build command I need is ghc --make.... Currently moving quickly onto stack this year.... From hvriedel at gmail.com Fri Sep 16 22:13:58 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 17 Sep 2016 00:13:58 +0200 Subject: [Haskell-community] Standard package file format In-Reply-To: (Harendra Kumar's message of "Fri, 16 Sep 2016 11:50:15 +0530") References: Message-ID: <8737kza3x5.fsf@gnu.org> (resent from different account, sorry if dupe) On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote: [...] > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. I'm not sure if this has been pointed out already, but beyond turning a proper grammar into a stringly-typed one, shoehorning some features of .cabal files into YAML syntax really appear like a case of the "Genius Tailor"[1], e.g. consider the `hpack` example when: - condition: flag(fast) then: ghc-options: -O2 else: ghc-options: -O0 besides looking quite awkward IMHO (just as an exercise, try inserting a nested if/then/else in that example above), the prospect that a standard format like YAML would allow to reuse standard tooling/libraries for YAML seems quite weak to me; if, for instance, you run the above through a YAML pretty-printer, you easily end up with something like when: - else: ghc-options: -O0 then: ghc-options: -O2 condition: flag(fast) or any other ordering depending on how the keys are sorted/hashed. Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if by accident you place a 2nd `else:` branch somewhere, you end up with an ambiguous .yaml file which may either result in an error, in the first key getting dropped (most likely variant), or in the 2nd key getting dropped. Which one you get depends on the YAML parser implementation. I really don't understand the appeal of applying the golden hammer of YAML, if `.cabal`'s grammar is already self-evident and concise with its syntax: if flag(fast) ghc-options: -O2 else ghc-options: -O0 where this if/then/else construct is encoded in the grammar proper rather than being merely a semantic interpretation after decoding a general grammar designed for simpler typed data-representations which isn't even accurate enough (since it has additional symmetries/freedoms) to capture the desired grammar faithfully, which make YAML quite error-prone for this specific application. [1]: The "Genius Tailor" was mentioned recently in a related discussion here: https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html -- hvr From harendra.kumar at gmail.com Fri Sep 16 23:53:20 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 17 Sep 2016 05:23:20 +0530 Subject: [Haskell-community] Standard package file format In-Reply-To: <8737kza3x5.fsf@gnu.org> References: <8737kza3x5.fsf@gnu.org> Message-ID: On 17 September 2016 at 03:43, Herbert Valerio Riedel wrote: > > I'm not sure if this has been pointed out already, but beyond turning a > proper grammar into a stringly-typed one, shoehorning some features of > .cabal files into YAML syntax really appear like a case of the "Genius > Tailor"[1], e.g. consider the `hpack` example > > when: > - condition: flag(fast) > then: > ghc-options: -O2 > else: > ghc-options: -O0 > > I agree. Supporting conditionals with YAML looks hacky! -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Fri Sep 16 21:57:58 2016 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 16 Sep 2016 23:57:58 +0200 Subject: [Haskell-community] Standard package file format In-Reply-To: (Harendra Kumar's message of "Fri, 16 Sep 2016 11:50:15 +0530") References: Message-ID: <87intva4nt.fsf@gnu.org> On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote: [...] > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. I'm not sure if this has been pointed out already, but beyond turning a proper grammar into a stringly-typed one, shoehorning some features of .cabal files into YAML syntax really appear like a case of the "Genius Tailor"[1], e.g. consider the `hpack` example when: - condition: flag(fast) then: ghc-options: -O2 else: ghc-options: -O0 besides looking quite awkward IMHO (just as an exercise, try inserting a nested if/then/else in that example above), the prospect that a standard format like YAML would allow to reuse standard tooling/libraries for YAML seems quite weak to me; if, for instance, you run the above through a YAML pretty-printer, you easily end up with something like when: - else: ghc-options: -O0 then: ghc-options: -O2 condition: flag(fast) or any other ordering depending on how the keys are sorted/hashed. Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if by accident you place a 2nd `else:` branch somewhere, you end up with an ambiguous .yaml file which may either result in an error, in the first key getting dropped (most likely variant), or in the 2nd key getting dropped. Which one you get depends on the YAML parser implementation. I really don't understand the appeal of applying the golden hammer of YAML, if `.cabal`'s grammar is already self-evident and concise with its syntax: if flag(fast) ghc-options: -O2 else ghc-options: -O0 where this if/then/else construct is encoded in the grammar proper rather than being merely a semantic interpretation after decoding a general grammar designed for simpler typed data-representations which isn't even accurate enough (since it has additional symmetries/freedoms) to capture the desired grammar faithfully, which make YAML quite error-prone for this specific application. [1]: The "Genius Tailor" was mentioned recently in a related discussion here: https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html -- hvr From hvriedel at gmail.com Sat Sep 17 06:29:02 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 17 Sep 2016 08:29:02 +0200 Subject: [Haskell-community] Standard package file format In-Reply-To: (Bardur Arantsson's message of "Sat, 17 Sep 2016 06:47:52 +0200") References: <87intva4nt.fsf@gnu.org> Message-ID: <87h99favkh.fsf@gnu.org> On 2016-09-17 at 06:47:52 +0200, Bardur Arantsson wrote: [...] > I was actually curious about this, and it's interesting to note that > even JSON which was supposed to have *ONE STANDARD* now apparently has > two, an ECMA one and and IETF RFC (seems to be more recent). Btw, that's partly because ECMA and IETF weren't able to agree who "owns" JSON, for more details see https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON -- hvr From qdunkan at gmail.com Tue Sep 20 18:25:15 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 20 Sep 2016 11:25:15 -0700 Subject: [Haskell-community] [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: I haven't totally followed this whole thread, so apologies if this isn't entirely relevant, but I use shake for building, and cabal for dependencies. The shakefile has the list of packages and required versions, and generates the .cabal file, which is used with --only-dependencies to get dependencies. I think it works well. I can't do builds in cabal anyway since it can't handle anything complicated, but even if I had a simple build I'd prefer shake since it's so much nicer. Since it's in haskell, it's flexible but can't be analyzed, though I can't think of why you'd want to analyze it. Meanwhile, cabal is just fine at expressing packages and versions, and is basically just a way to tell cabal-install what to download and install. Since I generate it, I don't care much about the format, but the existing one seems perfectly adequate. From michael at snoyman.com Mon Sep 26 10:32:57 2016 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 26 Sep 2016 13:32:57 +0300 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: I just realized that I had shared this answer on Twitter, but not on this mailing list. For those wanting to have direct access to GHC and other such tools, without needing to prefix calls with `stack exec -- `, the following added to your ~/.bashrc (or equivalent) will do the trick: export PATH=`stack path --bin-path` This can go as far as providing a means of using cabal-install, for example: https://gist.github.com/snoyberg/959a2ade4287de6129910eeabec1d9d2 For those without an established workflow, or open to experimenting with new workflows, I'd still recommend sticking with `stack exec -- ` in general, since it composes nicely with projects, letting you automatically switch to different GHC versions and package sets. But this is certainly another option to consider. On Tue, Sep 13, 2016 at 9:58 PM, Richard Eisenberg wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of > interest (as many of us have). The discussion inspired me to take another > look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build > tool for Haskell, I have never much liked stack. One of my chief goals in > taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This > machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I > really just want the ability to run Haskell expressions in GHCi. So I skip > `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages > along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: > /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed > delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I > got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment > of our community has not celebrated stack as much as other segments have. > We all have different workflows. > > From what I understand about it, stack is great for a project-based > workflow. In this workflow, you are working on a Haskell project. You are > happy to specify settings in .cabal and stack.yaml files. And you really > want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In > this workflow, you aren’t quite as organized perhaps and do not have all > your settings written. You also want the ability just to compile a file > without changing any configurations. You want to be able to start GHCi with > a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you > prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a > project-based workflow, and don’t use it when you want a compiler-based > workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The > downloads page right now is not serving us well. (I was legitimately > scratching my head at first trying to figure out how to provision a new > computer.) Sadly, I don’t see a good option presenting itself. Both > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > Platform Minimal) does appear to lack a “here’s what you do first” > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > discover — you have to choose the oft-maligned Haskell Platform link before > you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > warnings every time GHC is invoked outside of a project. Furthermore, stack > prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a > system GHC. Perhaps it would even be sufficient for `stack setup` to > clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we > should consider writing up criteria that potential users should consider > when choosing what workflow to start with. We’ll need to have a tighter > recommendation for those with no experience programming, but most > developers should be able to recognize what workflow they prefer and choose > accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > we’ll really be in a quandary about which installation procedure to put > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps > identified part of the burning black heart of the reason behind the vitriol > of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Sep 26 13:23:34 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 26 Sep 2016 09:23:34 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <181F4559-F28E-4BC2-9AAF-ABE344EF781A@cs.brynmawr.edu> 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Sep 26 13:36:10 2016 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 26 Sep 2016 15:36:10 +0200 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Sep 26 13:40:15 2016 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 26 Sep 2016 16:40:15 +0300 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: <181F4559-F28E-4BC2-9AAF-ABE344EF781A@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <181F4559-F28E-4BC2-9AAF-ABE344EF781A@cs.brynmawr.edu> Message-ID: On Mon, Sep 26, 2016 at 4:23 PM, Richard Eisenberg wrote: > Thanks, Michael, for repeating this here. (I'm not on Twitter, as you may > have figured out.) > > So, as I understand it, I could use the procedure below to install a > "system GHC", which could then be filled out with libraries by either > `cabal install xxx` or `stack install xxx`. > > If this is indeed the case, I will expect to recommend stack to my > students next semester, along with instructions of how to modify their > PATHs. I'd also be happy to reconsider recommending stack as the one option > on a downloads page, if we include the PATH updating instructions. > > This is _almost_ the case. When you use `stack install xxx` (or, for that matter, `cabal install xxx` inside a sandbox), no packages will be registered in the default user package database. Without modifying `GHC_PACKAGE_PATH`, those packages will not be available from a straight `runghc`. By contrast, `stack exec -- runghc` _will_ have access because it sets the `GHC_PACKAGE_PATH` env var. One possibility to overcome this is to just modify your ~/.bashrc to say: export PATH=$(stack path --bin-path) export GHC_PACKAGE_PATH=$(stack path --ghc-package-path) This is probably a fairly safe move overall, but it's not well tested (or, at least, _I_ haven't tested it well). Then you'd be able to `stack build some-library` and have it available. Or, leave off GHC_PACKAGE_PATH, use a `cabal install some-library` without a sandbox, and get the same result. (Typical downsides of lack of sandboxes would apply of course.) > With regard to `stack exec`: If I modify my PATH to allow direct calls to > ghc(i) and then create a project with a stack.yaml, won't `stack exec` use > the local settings, etc., when I'm in a subdirectory of the project? At the > bottom of your email, it sounds like you're recommending not modifying my > PATH, instead always using `stack exec` for a better experience. But it > seems to me that modifying my path allows me to skip the `stack exec` > outside of projects while still retaining the nice behavior inside of > projects, a net win to my eyes. (Your opinion on this may differ, of > course.) Is there something I'm missing here? > > It's really a matter of what you consider best, thus my referral to established workflows. If you use the PATH modification trick, and have a global configuration targeting GHC 8.0.1, and then go inside a directory that using GHC 7.10.3: * `stack exec -- ghc` will use GHC 7.10.3 * `ghc` will use GHC 8.0.1 Honestly, this somewhat gets to a point of trying to read the user's mind about what the anticipated behavior is. Personally, I've come to expect and enjoy the behavior of respecting the local settings, though there are certainly times when it's _not_ what I want. So take my recommendation to stick with `stack exec --` with a large grain of salt; as long as you understand that `stack exec ghc` and `ghc` in a given directory may behave differently, the PATH trick can work. And especially for teaching purposes, I can imagine the situation of multiple GHC versions to be a much smaller concern. > (Sidenote: You used `stack build` where I expected `stack install` in your > gist. I understand that the latter copies executables somewhere and the > former does not, but then it seems that the binaries are available in > `stack path --bin-path`, so I'm a bit confused.) > > Every project has a .stack-work directory, and (somewhere) inside of that is a /bin/ directory, where `stack build` automatically copies executables to. (A similar directory exists for each snapshot.) When you use `stack exec`, it adds these /bin/ directories to your PATH, so that you can easily run locally built executables. This is useful in many cases, but perhaps the most important is when you have an executable (like intero or ghc-mod) which is built against a specific GHC version: you're guaranteed to get the appropriate binary instead of whatever the last one to be installed happens to be. `stack install` by contrast copies this binaries out of those /bin/ directories and into ~/.local/bin (and somewhere else on Windows, I don't remember where offhand). This is a semi-standard directory for installing user built tools. This makes a lot of sense for tools like pandoc, stylish-haskell, hindent, etc: tools you'd want to use regardless of GHC version, and possibly when not working on Haskell code at all. > Thanks again for your input here! > Richard > > Pleasure, thanks for starting the conversation :) Michael > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > On Sep 26, 2016, at 6:32 AM, Michael Snoyman wrote: > > I just realized that I had shared this answer on Twitter, but not on this > mailing list. > > For those wanting to have direct access to GHC and other such tools, > without needing to prefix calls with `stack exec -- `, the following added > to your ~/.bashrc (or equivalent) will do the trick: > > export PATH=`stack path --bin-path` > > This can go as far as providing a means of using cabal-install, for > example: > > https://gist.github.com/snoyberg/959a2ade4287de6129910eeabec1d9d2 > > For those without an established workflow, or open to experimenting with > new workflows, I'd still recommend sticking with `stack exec -- ` in > general, since it composes nicely with projects, letting you automatically > switch to different GHC versions and package sets. But this is certainly > another option to consider. > > On Tue, Sep 13, 2016 at 9:58 PM, Richard Eisenberg > wrote: > >> I’ve watched the recent back-and-forth about stack with quite a bit of >> interest (as many of us have). The discussion inspired me to take another >> look at stack. Here are the results of that foray. >> >> First, a disclosure: While I have appreciated the emergence of a new >> build tool for Haskell, I have never much liked stack. One of my chief >> goals in taking another look is to understand better why I do not like it. >> >> My task: Set up a Haskell environment on a new machine (a Mac). This >> machine has no Haskell infrastructure on it. >> >> My approach: >> >> 1. `brew install haskell-stack`. Success. >> >> At this point, I do not have a Haskell project I wish to build. Instead, >> I really just want the ability to run Haskell expressions in GHCi. So I >> skip `stack new` and go straight to >> >> 2. `stack setup`. This succeeds, but prints out some interesting messages >> along the way, including >> >> > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of >> 71c0a55d0a877954d9590e285c0eb861ace2d8cc >> > Right Nothing >> >> At the end, I am helpfully told >> >> > To use this GHC and packages outside of a project, consider using: >> > stack ghc, stack ghci, stack runghc, or stack exec >> > >> >> So I then >> >> 3. `stack ghci`. My computer’s first reaction is to say >> >> > Run from outside a project, using implicit global project config >> > Using resolver: lts-6.17 from implicit global project's config file: >> /home/rae/.stack/global-project/stack.yaml >> > Error parsing targets: The specified targets matched no packages. >> > Perhaps you need to run 'stack init'? >> > Warning: build failed, but optimistically launching GHCi anyway >> > >> >> which doesn’t make me feel all that comfortable, but then I am indeed >> delivered to the GHCi prompt, which works as expected. >> >> Done with GHCi, I quit. I then want to double-check which version of GHC >> I got, so I >> >> 4. `stack ghc --version`. This command reports >> >> > Invalid option `--version’ >> >> Grumble. It seems I can’t interact with GHC directly. >> >> ———— >> >> At this point, I am reminded why I dislike stack: >> >> **It’s optimized for a different workflow than I use.** >> >> And I think this fact (repeated by others’ experiences) is why a segment >> of our community has not celebrated stack as much as other segments have. >> We all have different workflows. >> >> From what I understand about it, stack is great for a project-based >> workflow. In this workflow, you are working on a Haskell project. You are >> happy to specify settings in .cabal and stack.yaml files. And you really >> want your build to work in the future and on other machines. >> >> In my experience, stack is not great with a compiler-based workflow. In >> this workflow, you aren’t quite as organized perhaps and do not have all >> your settings written. You also want the ability just to compile a file >> without changing any configurations. You want to be able to start GHCi with >> a nice set of libraries with which to experiment. >> >> I definitely like a compiler-based workflow. I’m sure that many of you >> prefer a project-based workflow. >> >> The great news here is that we have a choice: use stack for a >> project-based workflow, and don’t use it when you want a compiler-based >> workflow. No one needs to convince others about personal preferences. >> >> But there is one nagging issue: what do we suggest to newcomers? The >> downloads page right now is not serving us well. (I was legitimately >> scratching my head at first trying to figure out how to provision a new >> computer.) Sadly, I don’t see a good option presenting itself. Both >> potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) >> serious shortcomings. >> >> A. The Haskell Toolchain (that is, what’s currently called the Haskell >> Platform Minimal) does appear to lack a “here’s what you do first” >> tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to >> discover — you have to choose the oft-maligned Haskell Platform link before >> you are told that there is a minimal variant. >> >> B. stack sets up GHC in a way that either 1) requires a project-based >> workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary >> warnings every time GHC is invoked outside of a project. Furthermore, stack >> prohibits direct interaction with GHC (as in `ghc --version`). >> >> There’s more good news here! Both of these problems are really easy to >> fix. >> >> To fix (A), someone just has to write the tutorial. >> >> To fix (B), stack just needs a new option so that `stack setup` installs >> a system GHC. Perhaps it would even be sufficient for `stack setup` to >> clearly tell the user where ghc is installed and what to add to their PATH. >> >> I also think, if readers agree with my conclusions about workflows, we >> should consider writing up criteria that potential users should consider >> when choosing what workflow to start with. We’ll need to have a tighter >> recommendation for those with no experience programming, but most >> developers should be able to recognize what workflow they prefer and choose >> accordingly. >> >> Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then >> we’ll really be in a quandary about which installation procedure to put >> first. Perhaps we should incentivize fixing (A) and (B) by saying whichever >> one happens first gets to be featured first on the page? :) >> >> So: Does my characterization of workflows resonate? Have I perhaps >> identified part of the burning black heart of the reason behind the vitriol >> of late? Should we fix (A) and (B)? >> >> I’m looking forward to hearing your thoughts. >> >> Richard >> >> >> -=-=-=-=-=-=-=-=-=-=- >> Richard A. Eisenberg >> Asst. Prof. of Computer Science >> Bryn Mawr College >> Bryn Mawr, PA, USA >> cs.brynmawr.edu/~rae >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Sep 26 13:42:58 2016 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 26 Sep 2016 16:42:58 +0300 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Tue Sep 27 15:02:54 2016 From: rf at rufflewind.com (Phil Ruffwind) Date: Tue, 27 Sep 2016 11:02:54 -0400 Subject: [Haskell-community] [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <1474988574.1362325.738549905.47548AAE@webmail.messagingengine.com> 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.)