Re: Improving the "Get Haskell Experience"
On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus
*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.*
[..]
We think this plan solves many different community needs:
- We have a clear way to "get Haskell" that works for a wide variety of use cases. - HP installer gets much smaller, and about as minimal as a working installation can get. - By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings. - By building and installing the Platform packages into it's own
db, users get the benefit of building and installing these common
only once per system, yet can easily bypass them for any given
Mark Lentczner wrote: package packages project if
desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work.
Sounds great to me! Personally, I do not mind how the Haskell Platform achieves these goals; I will simply adapt to whatever tools the platform happens to install on my machine.
Hopefully, they come with suitable documentation. For instance, one thing I don't understand about stack yet is in which location it "magically" installs GHC and packages, and how I can invoke `ghci` from these locations. Somehow, I was unable to understand this from the FAQ.
I think this FAQ entry should help[1] on the first question:
Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location.
For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set. [1] https://github.com/commercialhaskell/stack/wiki/FAQ#i-already-have-ghc-insta...
Michael Snoyman wrote:
Hopefully, they come with suitable documentation. For instance, one thing I don't understand about stack yet is in which location it "magically" installs GHC and packages, and how I can invoke `ghci` from these locations. Somehow, I was unable to understand this from the FAQ.
I think this FAQ entry should help[1] on the first question:
[1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..]
Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location.
Ah, ok. Can I assume that the non-sandboxed packages are also installed in the ~/.stack directory? That's the other part I didn't understand.
For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set.
`stack ghci` sounds good to me, then. I really like the short startup times of ghci and never use `cabal exec ghci` for that reason. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
On Fri, Jul 24, 2015 at 11:16 AM Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:
Michael Snoyman wrote:
Hopefully, they come with suitable documentation. For instance, one thing I don't understand about stack yet is in which location it "magically" installs GHC and packages, and how I can invoke `ghci` from these locations. Somehow, I was unable to understand this from the FAQ.
I think this FAQ entry should help[1] on the first question:
[1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..]
Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location.
Ah, ok. Can I assume that the non-sandboxed packages are also installed in the ~/.stack directory? That's the other part I didn't understand.
I'm not sure what "non-sandboxed packages" means. Do you mean snapshot-level packages? If so, yes. If you mean project-specific packages: they're all stored in the .stack-work directory of the project itself. My recommendation overall is: build a project with `stack`, and run `stack path` to get information on all of the different paths it's using for various things.
For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set.
`stack ghci` sounds good to me, then. I really like the short startup times of ghci and never use `cabal exec ghci` for that reason.
I think `stack exec ghci` is what you mean, correct?
Best regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Michael Snoyman wrote:
Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location.
Ah, ok. Can I assume that the non-sandboxed packages are also installed in the ~/.stack directory? That's the other part I didn't understand.
I'm not sure what "non-sandboxed packages" means. Do you mean snapshot-level packages? If so, yes. If you mean project-specific packages: they're all stored in the .stack-work directory of the project itself.
My recommendation overall is: build a project with `stack`, and run `stack path` to get information on all of the different paths it's using for various things.
Sounds good to me. I didn't know about the `stack path` command. Hopfully, that could be added to the documentation.
For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up < your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set.
`stack ghci` sounds good to me, then. I really like the short startup times of ghci and never use `cabal exec ghci` for that reason.
I think `stack exec ghci` is what you mean, correct?
Err, yes, thanks. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
participants (2)
-
Heinrich Apfelmus -
Michael Snoyman