Improve experience for one-off experiments

[UnkindPartition]

stack works quite well for cabal projects, but it's not that convenient for quick experimentation, where I just want to write some code to a file and run it or play with it in ghci, without creating a cabal file.

Here are some things that could be improved:

1. stack init currently refuses to create a stack.yaml when there's no cabal file
2. Even if there are no local packages, stack build could still build extra-deps.
3. It would be nice if stack ghci file.hs worked. stack exec ghci file.hs works for me, but that's probably not obvious to a Haskell newcomer (and Haskell newcomers really need a simple way to run ghci)
4. Related to the previous two items, we also need a way to force building a snapshot package so that it is available to non-cabalized stack ghci. I remember there was stack dep once, but it is no longer there.

[snoyberg]

For one off files I typically use stack runghc, and install necessary packages with stack build package-name. The script interpreter feature may also be relevant, as it shows some of the ways you can use the command line options for this.

[UnkindPartition]

I wasn't aware of stack build package-name; that should address point 4 above.

[snoyberg]

I don't understand the value of 1 or 2 given stack ghc and stack runghc. What use case are you thinking would need them?

[UnkindPartition]

You'd use stack.yaml to specify the resolver and, more importantly, extra deps. For instance, I want to play with gloss, but gloss isn't on stackage yet.

[snoyberg]

stack build can install packages that aren't in Stackage, it will just choose the latest versions, and you'll need to specify any missing dependencies. That's the same thing you'd have to do with a stack.yaml file. But letting stack.yaml work without a .cabal file is much more likely to cause user confusion based on what I've seen in the past.

As for (2): that would be a major regression for common use cases: we only want to build dependencies when they're necessary. Again, explicitly asking for a package to be built always works.

[UnkindPartition]

stack build can install packages that aren't in Stackage

I didn't know that either... and where do they get installed to? snapshot? global "default" db? how can you resolve eventual version incompatibilities (purge that database)?

[snoyberg]

The implicit global if you're not in a project. It follows all the same rules as a normal project: packages in the snapshot get installed to that database, otherwise to the local database. And if you try to install a conflicting package, it unregisters the old one.

You can certainly create a stack.yaml to avoid using the implicit global, I just don't see the value of changing stack init to allow that to outweigh the cost of people getting confused when stack init && stack build fails miserably.

[UnkindPartition]

Ok, I think this is good enough, thanks.

What about stack ghci file.hs?

[snoyberg]

@chrisdone you have any thoughts on the ghci aspects of this?

[ndmitchell]

The minimal feature I'd like is to have an extra entry in the YAML which says required-packages: [foo, bar] which resolves foo and bar and installs them before doing any other actions - basically automating away the stack build foo bar step. I don't want that to be driven off extra-deps since that requires version numbers, and I really just want "whatever is in the resolved" in most cases.

[ndmitchell]

See https://github.com/ndmitchell/shake/blob/master/website/stack.yaml for a concrete example, including comments of what I have to run. The stack build line is sad - without it I'd need no comments and it would all be obvious.

[snoyberg]

I'm worried about confusion with this issue regarding the original topic, the remaining GHCi point from above, and now the required-packages bit. I'll try to address the last one here, though.

As I see it, what this field would do would be to augment the current --package command line argument automatically. This would affect the exec, ghc, ghci, and runghc commands. I wouldn't see this having any impact on other commands, is that correct?

I'm still a bit on the fence about it, since this fields pretty ad-hoc, but I don't have a moral objection to it.

[ndmitchell]

@snoyberg - yes, that's what I'm suggesting. It is ad hoc if you are defining a system for building packages. If you are defining a system for one off scripts, it seems more principled - you are specifying the script dependencies. (I dislike the required-packages name - perhaps depends? I leave it to you)

Have you tried using Stack for one-off scripts yet? I guess there might be other features it requires to do it nicely, and I suspect myself and @feuerbach are groping around in the dark, but you might be able to see the overall principle.

[snoyberg]

I've always used the script interpreter approach for that, which doesn't
even require a stack.yaml file. For the record, it also works just fine on
Windows. One thing it doesn't address at all is the ghci case, but I'm
infamous for not using ghci enough myself.

On Fri, Oct 16, 2015, 12:39 PM Neil Mitchell notifications@github.com
wrote:

@snoyberg https://github.com/snoyberg - yes, that's what I'm
suggesting. It is ad hoc if you are defining a system for building
packages. If you are defining a system for one off scripts, it seems more
principled - you are specifying the script dependencies. (I dislike the
required-packages name - perhaps depends? I leave it to you)

Have you tried using Stack for one-off scripts yet? I guess there might be
other features it requires to do it nicely, and I suspect myself and
@feuerbach https://github.com/feuerbach are groping around in the dark,
but you might be able to see the overall principle.

—
Reply to this email directly or view it on GitHub
#1124 (comment)
.