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

[borsboom]

My personal experience has been that the script interpreter approach works well (including on Windows), and once a script reaches the point of complexity where it doesn't work well anymore, it's probably time for a .cabal file anyway. But I have no objection on principle to required-packages or something like that.

[ndmitchell]

I'm really after the ghci case - I tend to open ghci and :main rather than runhaskell anyway. I spend most of my life in both ghci and ghcid, so I guess me and Michael average out as both using ghci.

[borsboom]

Just to chime in: this seems like a useful idea to me as well. My main concern is that we make the distinction between packages, extra-deps, and this new option clear. In particular since the new option won't have much effect on the stack build case.

[snoyberg]

I haven't looked into detail yet, but #1217 may be related.

[ndmitchell]

My suspicion is that extra-deps is mislabeled, and should really be called extra-constraints, since they don't provide additional dependencies, merely extra constraints for existing dependencies. If you went that way, then this one would get the obvious name of extra-deps. Not sure that's feasible now though or not...

[UnkindPartition]

My suspicion is that extra-deps is mislabeled, and should really be called extra-constraints, since they don't provide additional dependencies, merely extra constraints for existing dependencies.

I don't think that's right. If a package is not in the snapshot, then it won't be available until you put it in extra-deps.

[ndmitchell]

But you aren't declaring extra dependencies, since these are already taken from the cabal file, you are only nailing down the dependencies you already have. Some of those aren't in the snapshot, so are required, but its only the constraint, not the dependency.

Of course, I also think that the snapshot should have everything in Hackage, but everything not listed as the current stackage should be bound to the latest, which then gives you a reasonable default when putting nothing.

[harendra-kumar]

#1361 looks like a dup of the stack ghci discussion here.

Related to this discussion - I was once contemplating allowing -- stack exec ghci in the interpreter comment. Then if you say stack file.hs it drops you into ghci. Will that be useful? Its a trivial fix. In fact it was working and I disabled it in interpreter mode along with other commands via #1504.

[mgsloan]

Yup, #1361 covers (3) and #2465 covers (1)