[Haskell-cafe] Using stack outside the project box

Tue Jun 8 19:43:20 UTC 2021

XMonad recompiles your config and then exec()s it, passing it some current
state. It's not the same as elisp.

On Tue, Jun 8, 2021 at 2:41 PM Galaxy Being <borgauf at gmail.com> wrote:

> But to my XMonad example. The Emacs world has the Emacs system running
> live, but the REPL capable of tweaking the live, running Emacs world in any
> way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.)
> Something similar must be happening with XMonad. After all, if I make
> configuration changes to xmonad.hs, somehow they must go into effect on a
> live, running XMonad, right? I don't log out of XMonad to a system shell,
> then compile the new executable with my config tweaks, then restart this
> new XMonad. No, I must be in some sort of Emacs-like situation -- or like a
> shell with C forking -- or some sort of event management device of XMonad
> where the "meta" XMonad is always running, but treating my config changes
> as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort.
> Or am I missing something? I think this is very basic information, but I
> sure can't find it anywhere. As I have come to understand the REPL from the
> Lisp world, it's a running virtual machine that allows live tweaking and
> programming. An executable, OTOH, is an independent agent living as a
> process on the host OS. In Emacs, with some languages you can even have
> separate org mode babel REPL sessions. But back to XMonad, I'm guessing
> it's a Haskell executable that then acts like a virtual machine that allows
> hot-swapping plug-and-play....
>
> On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites <jclites at mac.com> wrote:
>
>> On Jun 8, 2021, at 9:20 AM, Galaxy Being <borgauf at gmail.com> wrote:
>>
>> If I'm understanding correctly, I can follow the stack way of setting up
>> a project in a directory, then if I start a ghci REPL in that directory,
>> I'm in that project's sandbox, true? But if I start a ghci REPL in some
>> directory that has no stack project already set up, then that REPL is
>> relying on the global "project," so to speak.
>>
>>
>> Yes. The point of Stack is to allow different projects to use different
>> versions of GHC and different versions of libraries and have those projects
>> never interfere with each other. To do this it’s logically necessary for
>> Stack to always run based on a configuration file that tells it which set
>> of versions you want to use for this run.
>>
>> It's somewhat confusing since the project way of doing Haskell is to
>> compile with ghc, and run at a shell (same as C) and not have a running
>> ghci. Two different cultures.
>>
>>
>> In both cases you are compiling some Haskell code and running it. It’s
>> just that in the ghci case it’s doing both of those for you in one step.
>> Really ghci is just meant for experimentation.
>>
>> I think this is similar for most languages I’ve encountered that have a
>> REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not
>> directly using the REPL, even if the REPL happens to be built into the same
>> tool you use to run your program. The REPL is mostly a tool for quick
>> experimentation.
>>
>> Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a
>> loop around compiling and running some code. From that perspective, the
>> compile and run steps are the fundamental steps and the REPL is just a bit
>> of automation around those. It’s not the fundamental thing.
>>
>> It's difficult for me as a Haskell beginner to understand why beginner
>> tutorials all have me working with the ghci REPL
>>
>>
>> It’s because that’s the way to run small experiments quickly. They are
>> trying to teach you the language as concisely as possible, and not the
>> overall development environment. (Also, as a practical matter, the
>> instructions for setting up a development environment change and printed
>> books don’t, so including detailed setup instructions would be a waste
>> because they’d become out of date.)
>>
>> -- but then that's apparently not how real-world Haskell works. Or is it?
>>
>>
>> Correct; you don’t use the REPL to run large programs. You use it to try
>> things out.
>>
>> So Emacs is a running ball of C and Elisp code with an Elisp REPL that
>> gives you control over the running system.
>>
>>
>> Right. The Emacs case is different than others in that in this case your
>> elisp programs are (typically) extending the functionality of this
>> particular text editor, basically acting as plugin, rather than functioning
>> as separate programs that have nothing to do with a text editor. I wouldn’t
>> use Emacs as a model for conceptualizing other languages; it’s quite a
>> special case.
>>
>> Jeff
>>
>> On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <
>> travis.cardwell at extrema.is> wrote:
>>
>>> Sorry to hear that it is still not working for you yet.
>>>
>>> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
>>> > I installed stack on my Windows computer using chocolatey, which went
>>> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
>>> > prompt I tried to run stack ghci, then it started downloading and
>>> > installing stuff. Good. I then was able to track down an example of a
>>> > stack.yaml in the ...stack/global-project directory. My whole
>>> > motivation was to see an actual global stack.yaml in the wild, and not
>>> > have to guess-and-test from the stack docs.
>>>
>>> Stack provides functionality to initialize a project with a "template"
>>> so that you do not have to start from scratch.  For example, if you want
>>> to start a new project called "HaskellTest" in your `~/Dropbox/org`
>>> directory, run the following commands:
>>>
>>>     $ cd ~/Dropbox/org
>>>     $ stack new HaskellTest
>>>
>>> The default template provides you with a `stack.yaml` file that includes
>>> documentation and examples.  The template also provides you with a
>>> `package.yaml` file (used to generate the `.cabal` file using hpack)
>>> that has a library, executable, and test suite configured, as well as
>>> stub source code and various other files.
>>>
>>> Note that in cases where you already have a Haskell project (with a
>>> `.cabal` or `package.yaml` file), the `stack init` command can be used
>>> to add just the `stack.yaml` to the existing project.
>>>
>>> > Good. I duplicated
>>> >
>>> > packages: []
>>> > resolver: lts-17.15
>>> >
>>> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>>>
>>> Note that this `stack.yaml` file is for the "global-project" as it does
>>> not have any packages configured.  The `stack.yaml` file for any (other)
>>> project should list at least one package.
>>>
>>> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
>>> > started installing lots of stuff. (The resolver version I replaced was
>>> > lts-17.08. Why that old I don't know.).
>>>
>>> The resolver snapshot in the "global-project" is set when you first run
>>> Stack.  After that, it is up to you to update it *if/when* you would
>>> like to use a different snapshot.
>>>
>>> Similarly, the resolver snapshot for a project `stack.yaml` is set when
>>> you run `stack new` or `stack init`, and then it is up to you to
>>> maintain it as desired.
>>>
>>> > But then I got a cryptic error as it seemed to clash or not like
>>> > something it saw in some obscure github directory I had cloned ages
>>> > ago with Haskell example code. I deleted everything in the github
>>> > directory that looked stack/cabal-ish and tried stack ghci again. Now
>>> > it says
>>> >
>>> > Warning (added by new or init): Some packages were found to have names
>>> conflicting with others and have been commented out in the packages section.
>>> > Warning (added by new or init): Some packages were found to be
>>> incompatible with the resolver and have been left commented out in the
>>> packages section.
>>> > You can omit this message by removing it from stack.yaml
>>> >
>>> > Stack looks for packages in the directories configured in
>>> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
>>> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
>>> > but no .cabal or package.yaml file could be found there.
>>> >
>>> > Yes, that was the directory I purged. My
>>> > .stack/global-project/stack.yaml contains only
>>> >
>>> > packages: []
>>> > resolver: lts-17.15
>>>
>>> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
>>> being used.  It is likely that you are running `stack` commands in a
>>> directory that contains a `stack.yaml` file which references these other
>>> directories, and that file is being used.  Try (re)moving that
>>> `stack.yaml` file and trying again.  Do the errors persist?
>>>
>>> Once you (re)move the project `stack.yaml` configuration, the
>>> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
>>> configuration.  With the above content, the LTS 17.15 resolver will be
>>> used, with no packages configured.  As explained in my previous email,
>>> this does *not* expose libraries to GHCi.  If you want to expose
>>> libraries in the global project, you need to follow the instructions I
>>> gave previously for configuring the global project.
>>>
>>> > Not sure how to proceed. Seeing how that vast majority of Haskell
>>> > intro books don't use projects, just install, start ghci, load code at
>>> > the REPL prompt, I'd really like to nail this "global", non-project
>>> > stack down.
>>>
>>> Indeed.  Installation is tricky, particularly across multiple operating
>>> systems.  Most book authors avoid writing about it, as writing about it
>>> in sufficient detail would likely fill a book itself.  Most beginner
>>> books even stick with the `base` package so that readers do not even
>>> have to worry about packages.
>>>
>>> Global installation of packages leads to a *lot* of trouble when you get
>>> to more complex development.  When I first learned Haskell, I would
>>> occasionally completely remove my package database when I got into a
>>> situation that was difficult to resolve.  The situation improved a lot
>>> when Cabal introduced sandbox features, allowing dependencies to be
>>> managed separately per project.  Stack is project-based for the same
>>> reason: allowing each project to use separate sets of packages makes
>>> things a lot easier.  The "global-project" is called "global" because
>>> it is used when outside of any other Haskell project (determined by the
>>> existence of a `stack.yaml` file in the current working directory), but
>>> note that it is actually a project.  Following the instructions that I
>>> wrote in my previous email, you can configure Stack to work in the way
>>> that you want *without* running into the aforementioned trouble even
>>> when you start to develop other projects.
>>>
>>> Good luck!
>>>
>>> Travis
>>>
>>
>>
>> --
>> ⨽
>> Lawrence Bottorff
>> Grand Marais, MN, USA
>> borgauf at gmail.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.
>>
>>
>
> --
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.

-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/a5592fbf/attachment.html>