Stack: Wishlist: `stack run`

[andrewthad]

It would do the same thing as cabal run. For now, I can make due with a bash script I have, but this would be a good thing to add at some point.

[chrisdone]

Also: For now you can do stack build && stack exec foo.

[andrewthad]

I was unaware of that. Good to know.

[chrisdone]

(Because stack build installs the packages into the ~/.stack-work/ dir and stack exec runs things with that in its PATH.)

[snoyberg]

Given that stack build && stack exec foo works pretty well for this, do you have any objection with sticking to that as the recommended workflow? I'm concerned about using up the command namespace for something general like run with something that's easily achieved in another way.

[cocreature]

imho the current state is fine as long as there is some documentation. I didn't understand that this works before finding this issue.

[cocreature]

I added it to the transition page on the wiki.

[snoyberg]

Cool, good call. I was about to ask you where you thought a good place would be to cover that.

[cocreature]

I am actually not quite sure what belongs to faq and what belongs in the transition page. I imagine the questions people ask most frequently are probably related to a transition so it's hard to make that distinction.

[chrisdone]

So we close this one?

[snoyberg]

@cocreature I agree, it's unclear what should go where. We may need to change the break-up of the pages, it was just the first thing that came to mind when I started on it. Suggestions welcome!

@chrisdone Yes, let's close it.

[johnynek]

What if stack exec without args ran the first (is more than one allowed?) executable in the .cabal file? Right now, without args you get a help message (which could be there with stack exec --help?).

[Wizek]

+1 for stack run. I find myself reaching for it quite a few times. I have a workaround script installed in my main dev env named stack-run, but whenever I install stack on another machine I get surprised that it's unavailable. Also would be nice for it to work like cabal run.

@snoyberg You mention a concern about command namespace filling up. Are you still concerned with that? If so, can you imagine any competing feature(s) that might have a claim for stack run that would not do the same/something similar to cabal run?

[snoyberg]

Yes, I'm still concerned with it in general, but I also won't block the
feature if it's generally desired.

On Fri, Mar 30, 2018, 5:58 AM Milán Nagy [e-mail] wrote:

+1 for stack run. I find myself reaching for it quite a few times. I have
a workaround script installed in my main dev env named stack-run, but
whenever I install stack on another machine I get surprised that it's
unavailable. Also would be nice for it to work like cabal run.

@snoyberg https://github.com/snoyberg You mention a concern about
command namespace filling up. Are you still concerned with that? If so, can
you imagine any competing feature(s) that might have a claim for stack run
that would not do the same/something similar to cabal run?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commercialhaskell/stack/issues/233#issuecomment-377432028,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBB3V89Jz5Ja_EfKMehpWjM-Yhux5dks5tjZ9CgaJpZM4E9aHd
.

[Wizek]

Hey @rszibele, thank you for starting to work on this and submitting a PR, I hope the feature will get merged.

Wrt 'general desire' for the feature, there is also this related stack overflow question: https://stackoverflow.com/questions/34842333/is-there-a-stack-run-similar-to-cabal-run/35107441

[rszibele]

Would there be any objections to being able to specify in the stack project which executable should be run by stack run and fall back on running the first available executable if it isn't defined?

[Wizek]

@rszibele no objection from me. I'm not even sure if cabal had support for such a configuration, and I was able to use it fine without, so this is not a requirement from me. Many of my projects build a single executable anyway, but that may change. So I guess it's not required, but could be nice to have.