Scripts supplemented by versioned bins

[bcomnes]

Have you given any thought or considered adding support for versioned tools similar to how npm supplements its script environment PATH with node_modules/.bin?

Not exactly sure what that would look like in a deno project, but roughly you would would list deno installable cli urls (and maybe permission flags) in a project file, have them installed into a local project folder, and then supplement the script shell's path to include these.

Thoughts? Maybe there are other tools out there providing this?

[bcomnes]

Didn't see the discussions sections, sorry for making an issue.

[umbopepato]

No worries @bcomnes 🙂

[umbopepato]

This would be very helpful! In this same project I found myself using external npx commands in vr scripts in order to avoid a manual installation step (or semi-manual, like a setup script).

I think the hard part is finding a reliable way to store dependency data from which to reconstruct installation commands: some CLIs don't even use deno install (see lume for example). On the other hand, storing complete installation commands is not different from providing a manual setup script:

scripts:
  setup:
    - deno install ...
    - deno install ...
    - deno run ...
  myscript: # use the installed deps here

Also, storing deps launchers in a local folder is a very cool idea! Should be pretty easy to implement using deno install --root and would take orders of magnitude less space on disk compared to node_modules, but again: not every CLI uses deno install...

[umbopepato]

A (slightly unrelated) feature I've been thinking about that could help with this is using script config files to allow CLI authors to specify installation data:

# somecli/scripts.yaml

install:
  entry: ./path/to/entry.ts
  allow: [env, read, write]
  # Other install params

scripts:
  ...

So that consumers of somecli can install it globally or locally with simple commands:

$ vr install -g somecli # Global
$ vr install somecli    # Local

The latter would save somecli's specifier + version to the user's vr config and install it in a local folder (as per your proposal):

# mymodule/scripts.yaml

deps:
  somecli: ^1.2.3

scripts:
  myscript: # Use somecli here

This would be restricted to CLIs that use deno install and Velociraptor though 😬

[bcomnes]

I guess a rough sketch of the idea from my end would be like this:

# scripts.yaml
scripts:
  start: file-server .
  post-gist: gist ./foo.bar

tools: # these are for supplementing scripts with localized tools, not project code dependencies. Possibly a clearer name. 
  file-server: # you can rename the bin here
    url: https://deno.land/std@0.97.0/http/file_server.ts
    allow: [net, read]
  https://deno.land/std@0.97.0/examples/gist.ts: [net, read] # alternative syntax idea

vr would then either support an install step that preps the tools, or maybe in a more deno-y fashion, always install/prepare the tools (saving time by pulling from the cache) whenever you run a script (similar to how deno run treats dependencies). This could also offer a similar shortcut to npx e.g. vr run file-server . pulling tools specified from scripts.yaml.

This would be restricted to CLIs that use deno install

Yeah, that would be the initial limitation, supplemental project local clis and tools would have to be installable via deno install (at least as a starting point with this idea). It does look like loom offers a deno installable version of the tool "for CI", but I'm not sure what the differences are. I think it's a fair restriction to at least begin with to see how far it can be taken.

and Velociraptor though 😬

The ideal sketched above would put no dependency on vr for CLIs. Maybe your install: field could help provide a shortcut to generating the slightly verbose permission syntax in the deps/tools section? e.g. vr install https://deno.land/std@0.97.0/http/file_server.ts resulting in the above addition to the tools field (or whatever it ends up getting called). It would be merely supplemental.

Storing deps launchers in a local folder

I'm not even sure thats the 'best' way to do it. Maybe a more deno-y way would be to cache CLIs by the URL they are installed by (or whatever they resolve to the case of semver supportive CDNs) into a global cache (does deno do this already with deno install?), and then symlink them into a local folder, or just reconstruct the PATH to include them all in the script environment. Not sure. The core idea here being, try to follow the design and patterns of deno as close as possible.

[umbopepato]

vr would then either support an install step that preps the tools, or maybe in a more deno-y fashion, always install/prepare the tools (saving time by pulling from the cache) whenever you run a script

Oh sure, the main purpose of the install command would be to resolve a dependency identifier/deno install command and convert it to a configuration deps/tools entry and maybe prepare the deps for the first time. vr would then perform a check of locally installed deps against the config on each execution.

I think it's a fair restriction to at least begin with to see how far it can be taken

Indeed. The majority of CLIs use deno install.

The ideal sketched above would put no dependency on vr for CLIs. Maybe your install: field could help provide a shortcut to generating the slightly verbose permission syntax in the deps/tools section?

The idea of the install field is to allow users to vr install [-g] somecli instead of deno install <a ton of arguments> (and maybe on the other side to only save the specifier and version in the deps section instead of all the install parameters?). As for the CLIs that don't use vr we could accept the exact same arguments of deno install and save them in a dedicated tools entry:

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

becomes

$ vr install --allow-net --allow-read -n serve https://deno.land/std@0.97.0/http/file_server.ts

and is saved (using an extension of the format already used by scripts) as

deps:
  serve:
    entry: https://deno.land/std@0.97.0/http/file_server.ts # Or std@0.97.0/http/file_server.ts with auto registry resolution?
    allow: [net, read]
    name: serve

Also, I like the entryfile: [permissions] syntax, but I doubt it would be enough since many install commands use other params like --name, --import-map etc.

[umbopepato]

@bcomnes I created a feature issue to summarize all this, see #63

[bcomnes]

Sorry for the slow delay, I'm maybe buying a house so I've been super preoccupied. I read your idea and it looks great!