version-manager/woof

The version manager to end all version managers.

woof's Issues

Error if give arguments to subcommand that is expecting none

Specify groups of modules

Be able to disable/enable groups and single plugins

Support using `latest` as version

Rework TUI

Future development is blocked on a better TUI for expressing actions and the like. The current TUI works, but is one dimensional and does not support many features

To make this possible, I'm writing a Bash TUI library. It builds upon bash-term. When its ready enough, I'll make it public at hyperupcall/bash-tui and use it from this project.

The final TUI should look something like this:

plugin 1   |  [tool a] [tool b] [tool c] 
plugin 2   |  [variant a] [variant b] [variant c]
           |
           |
Sidebar    |
           |
           |
           |
           |
----------------------------------------------------------
                            status bar

Until then, this place will be relatively desolate

Somehow `hash` after resymlink or local install

• Can do so with a shell function, but that would necessitate duplicating argument parsing code
• Can create a file at /tmp/woof-reshim that, if exists, tells shell function to hash (easiest)
• Create background process for each spawned shell that will hash via IPC
  • Long term solution, as similar to the history

Handle plugin versions

Add version field
Add 'tool' subcommand for to generate release for a plugin

Finish `--dry-run`

print what bins are being installed to and where etc

Put all plugin extracted contents in root

ex. installs/boundary/v0.10.0/* (no files/)

404: https://hyperupcall.github.io/woof

https://hyperupcall.github.io/woof is this project's URL. Change it to https://version-manager.github.io/woof/ .

deno: New update would you like to install screws up installation

This directly writes to the current executable, making it so that a directory that says v1.25, may actually be v1.25.1

Find some way to fix this

Fix `fatal` and `error` things

Some things should show fatal, others should show 'error'. This needs to be consistent with other projects

Track symlinked files for each `plugin`

So when switching between different variatns, can unlink everything in that particular plugin (without unsymlinking absolutely everything, which will wreck performance and behavior (since its a race condition)

Check

Check version tables and make sure that for each version, architecture, and platform that there are no duplicates

• This would catch at least Please (since there is a server/client binary) for super early versions

Also check to ensure version matches regular expression of semantic version or date

• This would catch FStar, where early versions are just weird

Additional tools

Use this issue to track what additional tools to add:

• hermit packages
• asdf plugins
• sdkman
• languages from here

show help menu for each individual command

Allow for passing multiple 'plugins' for each subcommand

optimize: do not source all `src/commands` files

Change defaults for set-version get-version

Make the default local, then if no local can be found, do global (and print message saying it changed global version)

Have a --global flag to override

Stop reallocating arrays and instead use variable references

Interactive `.tool-version` updates

From asdf: asdf-vm/asdf#1235

Add `--lts` flag to `woof list`

Solidify extracting utilities

Mostly different file endings to tar and zip

Add stacktracing

Doesn't work with tmuxinator

stdin is not a terminal until an interactive bash terminal is executed within the session

New Languages

• Neovim

Use `n`'s behavior of sharing global module directory?

Potential code

	# TODO
	# Here, we ensure that the correct corresponding npm version is installed
	# when switching versions. 
	# mkdir -p "$WOOF_MODULE_COMMON_DIR/node_modules"
	# m.ensure rm -rf "$WOOF_MODULE_COMMON_DIR/node_modules"/{corepack,npm}
	# m.ensure cp -r "$PWD/dir/lib/node_modules"/{corepack,npm} "$WOOF_MODULE_COMMON_DIR/node_modules"
	# m.rmln "$WOOF_MODULE_COMMON_DIR/node_modules" "$PWD/dir/lib/node_modules" 

We'll want this to be shared for all versions (global, directory, etc).

Make console output to right of colon gray rather than white

      Info: Constructing version table
  Fetching: https://nodejs.org/download/release/v18.1.0/node-v18.1.0-linux-x64.tar.gz
################################################################################################################################################################### 100.0%
 Unpacking: /storage/ur/storage_home/Docs/Programming/repos/Groups/Bash/woof/woof/state/workspace-nodejs/./file.tar.gz
41.6MiB 0:00:00 [52.8MiB/s] [==========================================================================================================================>] 100%
 Installed: v18.1.0
     Using: v18.1.0
      Info: Setting v18.1.0 as global default for nodejs

Implement a `<plugin>.build()` function

Automatically reshim

asdf: asdf-vm/asdf#409

Polish

• woof list (make this work better)
  • Make --all the default if none are supplied on the command line
• Error if give arguments to subcommand that is expecting none
• Allow for passing multiple 'plugins' for each subcommand
• what to do with the prunes? (put them at the bin/woof.sh file)
• Add version metadata to plugins
• think about refactor to use globally variables. $tool_name, $plugin_name, etc. and the like. these values are only mutated in particular places at the start of program execution. makes things easier, maybe will even improve perf due to fewer allocations
• change install_dir/blah to tools_dir because that's what it is

Add exec subcommand

Add exec subcommand

Have function that returns the executable command

for example

• woof exec nodejs [version]
• `woof get-version --full [dir

Then, something like /home/user/.local/state/woof/installs/nodejs/v18.0.0/bin/node etc. is printed to stdout

Symlink to project `./bin` like hermit

Support more formats in `.tool-versions`

Support the full list of .tool-version formats

They include

• ref:*
• path:*
• system

in other files like .rvm there may or may not be a leading v

Improve plugin install

• Support multiple arguments
• Shorthand for woof-plugin repositories in version-manager repository

force install that continues even if it already exists

Clarify plugin naming and usage

In some areas, plugins are prefixed with woof-plugin-*. At other times, they are not. Unify this.

Clarify how tool selection works when a plugin only has ONE tool, or it wants to choose a tool by default.

For example, the python tool may have the tools python, micropython, jpython.

• python:{python,micropython} -> does what you expect
• python -> show tool selection menu
• python/ -> show tool selection menu
• python/:default
• python/p

Change default 'out' directory

Currently, all directories are named 'dir' before copying their extracted contents to the <tool>/<version> directory.

I'd like to make the name less generic - to something like 'out', 'extracted', or 'final'

Installation

When installing this on actual systems, have an option to be via package manager

That way on servers, PATH is already sorted out. Or, install to /opt via install script with various symlinks to bin /usr/local/bin

Change `--global list` to _only_ use cache. Do _not_ automatically fetch

Improve error messages

Stuff like "Failed to find corresponding row in version table" etc. should be devoid of implementation detail

inside `installed-tools`, each tool should be prefixed with the slug of its owning plugin

this requires to push parameters like $tool_name in a lot more places.