possible cargo-script-run

[nathanross]

Hashbang-callable and automatically suppresses cargo compile messages except on compile error. i.e. STDOUT (and stderr) of executing a successfully-compilable script is always just the product of the compiled script's execution.

This is so for bash, python, etc. scripts which other programs/scripts execute directly and use the stdout, a rust file+cargo-script can be used as a drop-in replacement.

#!/bin/sh
# cargo-script-run 

if ! results=`cargo script --build-only $1 2>&1`; then
    echo -e "$results"
    exit 1
fi
cargo script $@
exit 0

OTOH I can see the value of saying "if you're going to be using it as an executable called by other programs, make it into an actual rust project." So it's just an idea.

[DanielKeep]

This looks fine, aside from possibly wanting to put quotes around the arguments.

I still do not know how to distribute this, though. cargo script has no Makefile or configure script, and *nix users presumably want some kind of installation... well, aside from Nix'ers, but they're all weirdoes. I'd have to read up on what the best practice is.

[DanielKeep]

I've committed a new binary that basically does this.

I chose to go with another full program on the basis that such a program will work on any platform supported by cargo-script without having to worry about what shell is being used. It can also serve as the target for Windows file associations; there's no need for a separate program in that case, but it does help unify the behaviour.

This leaves two things:

1. Should the name cargo-script-run be used? The problem is that it makes cargo script-run a supposedly valid command, despite being 100% unusable. Perhaps it should be renamed to run-cargo-script.
2. It doesn't do the "hold the output except on error" thing. I'm a little leery of this behaviour because the first build of a script can be incredibly slow; without feedback, a user might assume the program has hung. Secondly, if I do enable this behaviour, I'd prefer to do it with a pair of fuse streams, in order to preserve stdout and stderr.

One possible compromise for number 2 would be to have the fuse blow if the compile doesn't finish in under a certain timelimit, but I'm unsure if that's a good idea or even feasible in a portable fashion.

Edit: I'll leave this issue open until the runner is merged into master and released.

[kbknapp]

There is a way to run the runner as the stand alone cargo-script and the normal cargo-script from cargo script. This is a fortunate biproduct of cargo calling third party subcommands with the name of the subcommand as an argument to the third party subcommand binary.

So what is now run-cargo-script would be invoked by running cargo-script [options] and the actual third party subcommand wouldn't be changed at all (invoked by cargo-script script [options]). This is made trivial with claps "global args" which are just arts which are propagated down through child subcommands.

See carols10cents/cargo-open#10 for an example of a cargo subcommand doing this.

This is even more fortunate because it looks super consistent to users.

[DanielKeep]

The problem with this is that it all falls apart the instant the user calls their script script, with a rather unhelpful error message. On the whole, I prefer something that always works over something that works 99% of the time and turns into a sentient bowl of petunias the other 1% of the time.

[DanielKeep]

Actually, run-cargo-script is in master, so this can be closed anyway.

[kbknapp]

The problem with this is that it all falls apart the instant the user
calls their script script, with a rather unhelpful error message.

That's a good point, fair enough :)

On Mon, Nov 16, 2015, 8:58 AM Daniel Keep notifications@github.com wrote:

Closed #7 #7.

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