installed programs should be able to take --reload argument

[ry]

If I install a program

deno install catj https://deno.land/std/examples/catjson.ts --allow-read

I want to be able to use flags like --reload or -L=info with the newly installed program:

catj --reload

^-- does not work as intended.

[axetroy]

Here is an example.

flags can be got by the installed program

> deno install echox https://github.com/denoland/deno_std/raw/master/installer/testdata/echo.ts

> echox hello world --reload
hello, world, --reload

I really don't known where the problem is.

[ry]

I mean that the --reload flag should be passed through to deno, in order to download a new version of the code. The problem comes from the ordering of arguments.

In the future we will have the "--debug" flag. It would be very nice to be able to do "echox hello world --debug"

[bartlomieju]

This is gonna be tricky... Clap (our CLI parser) doesn't support out use case, where we'd like to pass global flag after last argument (because after subcommand, rest of args is forwarded to script as Deno.args). Only solution that comes to my mind is hacking in bash/PowerShell to check for recognized Deno arguments in argument array (like -r/--reload) and passing them to deno instead of script.

Example (pseudo code)

if "-r" in $@
  $args = filter($@, i != "-r")
  deno --allow-read --reload https://deno.land/std/examples/catjson.ts $args

[ry]

Maybe we can hack clap? I don't like the bash solution.

[hayd]

One problem, which we had with --help is what if a deno program wants to use that.
What is the usecase (why would a user want to do this)?

Is it easier/sufficient to do something like:

deno install --update catj https://deno.land/std/examples/catjson.ts --allow-read --refresh -L=info

[kt3k]

How about supporting env variables for controlling those?

DENO_RELOAD=1 catj # => deno run --reload ...
DENO_DEBUG=1 catj # => deno run --debug ...

[bartlomieju]

One problem, which we had with --help is what if a deno program wants to use that.
What is the usecase (why would a user want to do this)?

To provide help/usage message for the program, check //deno_std/examples/catjson.ts

Is it easier/sufficient to do something like:

deno install --update catj https://deno.land/std/examples/catjson.ts --allow-read --refresh -L=info

The problem I have with this command (it was already prototyped in denoland/std#512) is that you have to type full URL again - so actually it's the same as installing the program again. I'd be willing to settle on deno upgrade <exe>. This solution can be easily achieved by modifying script files - they just need to expose URL of the module.

How about supporting env variables for controlling those?

DENO_RELOAD=1 catj # => deno run --reload ...
DENO_DEBUG=1 catj # => deno run --debug ...

-1 for more env variables, let's figure out how to make flags work to our success.

Maybe we can hack clap? I don't like the bash solution.

I'm not sure, but on first sight I'd be pretty hard... I believe that bash solution is lowest hanging fruit.
Another solution we might consider is using -- for script args:

$ deno install catj https://deno.land/std/examples/catjson.ts --allow-read
$ catj --reload -L=info -- file1.json file2.json // all args before `--` are passed directly to Deno
$ catj file1.json file2.json // no `--` - pass all args to script

This is still pretty esoteric... Let's look for reference in other implementations

[hayd]

The problem I have with this command (it was already prototyped in denoland/std#512) is that you have to type full URL again

For an update there's no reason that has to be the case (you could reuse the existing if not passed).

I still don't see the use case for this, when/why would regular users want to do this?

[ry]

The idea of this feature is that "installed programs" should still act as other Deno programs, with the ability to be debugged, to change the logging style, reload the source code.

catj --reload # should fetch a new version
catj -L=info  # should log permissions
catj --debug  # eventually should start the ws server for devtools

[NamPNQ]

I think it is misleading with program args
What happens if the program handles the same this args?

[ry]

Maybe we can filter out these arguments? It's especially troublesome in the situation of "--help" where you would hope that catj --help would pass the argument through to catj, but if we filter all arguments that deno supports blindly it wouldn't work.

[bartlomieju]

Maybe we can filter out these arguments? It's especially troublesome in the situation of "--help" where you would hope that catj --help would pass the argument through to catj, but if we filter all arguments that deno supports blindly it wouldn't work.

Then we arrive at solution proposed in this comment. Maybe it's not that bad after all? We'd have to support only 6 flags (3 options, each with short and long option).

[ry]

@bartlomieju I see the shell scripts as a very minimal way of launching into Deno. We should keep logic in Deno where it can be tested and modified. Shell is a terrible language to write in compared to Rust/TS. If we write the logic to bash scripts, there will be no way to change that after installation. Shell also isn't portable, so we'd end up having to duplicate the efforts on Windows

I think it's very nice that the installed shell scripts are basically just a URL - it's easily understood by anyone even if they don't know how deno is working.

[NamPNQ]

I think we can add prefix, it's more clear
catj --deno-reload
catj --deno-debugger

[bartlomieju]

@bartlomieju I see the shell scripts as a very minimal way of launching into Deno. We should keep logic in Deno where it can be tested and modified. Shell is a terrible language to write in compared to Rust/TS. If we write the logic to bash scripts, there will be no way to change that after installation. Shell also isn't portable, so we'd end up having to duplicate the efforts on Windows

I think it's very nice that the installed shell scripts are basically just a URL - it's easily understood by anyone even if they don't know how deno is working.

@ry I see your point. I just had another idea come to my mind:
After flags and args are parsed into DenoFlags I can also parse remaining arguments forwarded to script as DenoFlags and merge them, example

$ deno --allow-net script.ts --reload --allow-write
// would be equivalent to 
$ deno --allow-net --reload --allow-write script.ts

$ deno script.ts -D --help
// equivalent to 
$ deno -D --help script.ts 

We'd have to decide if those flags should be "eaten" by parser (1) or still forwarded to script (2):

// 1. 
$ deno --allow-net script.ts --reload --allow-write
// equivalent to
$ deno --allow-net --reload --allow-write script.ts
// Deno.args
["script.ts"]

// 2. 
$ deno --allow-net script.ts --reload --allow-write
// equivalent to
$ deno --allow-net --reload --allow-write script.ts
// Deno.args
["script.ts", "--reload", "--allow-write"]

Third option would be to control this behavior by another flag (say --parse-script-args):

// no `--parse-script-args`
$ deno --allow-net script.ts --reload --allow-write
// equivalent to
$ deno --allow-net script.ts
// Deno.args
["script.ts", "--reload", "--allow-write"]

// with `--parse-script-args`
$ deno --allow-net --parse-script-args script.ts --reload --allow-write
// equivalent to
$ deno --allow-net --reload --allow-write script.ts
// Deno.args
["script.ts", "--reload", "--allow-write"]

[ry]

@NamPNQ Eh. I would hope we can find something more elegant.

@bartlomieju That sounds like a hack that could work. I think the args should be eaten.

[bartlomieju]

@ry good! I'll raise a PR so we can iterate on the idea.

[hayd]

I still haven't heard a use case.

It seems to me this is a micro optimization for deno core developers.. but not useful for users.

[bartlomieju]

I still haven't heard a use case.

It seems to me this is a micro optimization for deno core developers.. but not useful for users.

@hayd suppose you're installing file_server from deno_std:

$ deno install file_server https://deno.land/std/http/file_server.ts --allow-read --allow-net

Command above will install latest available version of http/file_server.ts. Until you call file_server --reload it won't download latest version of code.

Of course this situation disappears if you installed from tagged URL (https://deno.land/std@v0.9.0/http/file_server.ts).

I think --debug flag is most useful in this context.