This used to show up but doesn't anymore.

Looks like the new default install path for brew is in /opt/homebrew. The alt scan ... command should support that.

I have had multiple co-workers come up to me complaining about alt not working. In every case, alt was showing a warning about the shims dir not being in the PATH but they never noticed.

Steps to reproduce

You'll need a sacrificial command for this. In my case, I'm going to user ruby.

1. Define command

   alt def ruby test-sys /usr/bin/ruby

2. Make sure the shims exist

   alt shim

3. Run your command as root

   sudo ruby --version

alt will call itself in a loop complaining that it's not configured properly.

Why is this happening?

1. sudo invokes alt (through a shim)
2. It passes your user's PATH env var (including your user's shim dir $HOME/.local/alt/shims)
3. alt tries to find the system version of the command (presuming that alt is not configured for the user you're sudoing into)
4. alt finds your original user's shim dir ($HOME/.local/alt/shims/ruby) (it didn't filter it out because it thinks the shims dir is the one for the user you sudoed into ex: /root/.local/alt/shims)
5. alt invokes its own shim
6. goto 1

Deeper problem

alt can invoke itself in a loop. Seems like it's pretty bad at detecting when it's calling itself.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

If you follow the installation instructions to the letter, you end up with a broken version of alt.

The instructions are roughly like so:

1. Install the binary
2. Add the shims dir to your PATH
3. You're done

The problem with this, is that users are left in a shell where the PATH does not contain the shims dir. This means that alt will not work in their current shell.

The latest release (v1.0.3) failed to build the ARM binaries.

Example: https://travis-ci.org/dotboris/alt/builds/504405085

The failure was caused by the strip command not knowing what to do with the arm binaries.

$ strip "target/$TARGET/release/alt"
strip: Unable to recognise the format of the input file `target/arm-unknown-linux-gnueabi/release/alt'
The command "strip "target/$TARGET/release/alt"" failed and exited with 1 during .

Right now, if the scan fails to find your command versions, you're stuck with having to edit the defs.toml file.

We should at least have a command that lets users define a command version.

Recently Travis CI announced that they were effectively dropping their free plan. Technically it's possible to get free access to Travis CI for OSS projects but that requires asking them nicely. I don't think that it's worth the time and effort to jump through the hoops that Travis CI has laid out here.

Currently, alt is running travis-ci.org which is going to go in read-only mode on December 31st. See: https://docs.travis-ci.com/user/migrate/open-source-repository-migration/#q-what-will-happen-to-travis-ciorg-after-december-31st-2020
We can migrate to travis-ci.com. This will give us a plan with some free credits that will eventually run out.

Todo

• Setup code quality checks with github actions
• Configure automatic release pushing with github actions
• Remove travis ci config & badge
• Remove all travis-ci creds

The CI will build arm binaries for arm v6 arm v7 and arm64 but the install script does not support installing those.

https://github.com/dotboris/alt/blob/master/install.sh#L20-L36

A little while back Travis effectively dropped it's free tier for OSS projects making it unusable for us. See #137 for the details. In #137 we have migrated the code quality part of the CI. In process we lost the automated deployment / release. We didn't end up implementing it.

The automatic deployment needs to do the following:

• Update the changelog
• Update the version number
• Commit those changes
• Tag the new version
• Build all packages
• Push packages to github release

Here's a simple example:

$ alt def node 18 ./opt/node-18.12.1/bin/node
$ alt use node 18
Will now use node 18 (./opt/node-18.12.1/bin/node) when in /home/dotboris
$ node --version
v18.12.1
$ cd code/dotboris-io
$ alt show
Versions from: /home/dotboris/code/dotboris-io/.alt.toml
node
 * 18 (./opt/node-18.12.1/bin/node)
python (using system)
   3 (/usr/bin/python3)
$ node --version
🔥 alt failed to run node version 18!
error: Os { code: 2, kind: NotFound, message: "No such file or directory" }
command: node
command version: 18
args: ["--version"]
bin: ./opt/node-18.12.1/bin/node
current dir: Ok("/home/dotboris/code/dotboris-io")
thread 'main' panicked at 'explicit panic', src/exec_cmd.rs:47:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The core of the issue is that alt def takes the path its given as is and stores it. When this path is relative, it's sensitive to the current directory which doesn't work in most cases.

The simple solution here is to make the path absolute before storing it.

Currently, users are expected to define the different versions of commands by hand in ~/.config/alt/defs.toml. This is pretty annoying.

On most systems it should be pretty simple to detect multiple versions of installed commands. For instance:

• Commands in the PATH with a version suffix. Things like /usr/bin/python2 and /usr/bin/python3.
• Homebrew (OSX package manager) supports installing multiple versions of commands. Officially supported older versions of a command have an @ in the package name. Example: node@8 and node@8
• Java support running multiple versions of the JRE / JDK in a pretty standard directory
• The alternatives system under linux can let us find commands with multiple versions
• Package managers could let us find multiple versions of command if we figure out some sort of suffix pattern
• Install tools like ruby-install and node-build can be queried to find multiple versions

We don't necessarily need to support all of these, but the idea is to have a good enough coverage to let most users just run a command and be ready to go

Hi, I would like to use your command to switch between golang versions, but the alt command compliant with the following:

➜  ~ alt scan go
Sorry, could not find any versions of go

So, here are some outputs to show you my current situation of my workstation:

➜  ~ go version
go version go1.11.13 linux/amd64
➜  ~ which go
/usr/bin/go
➜  ~ ll /usr/bin/go
lrwxrwxrwx 1 root root 20 Aug 15 15:00 /usr/bin/go -> /etc/alternatives/go
➜  ~ ll /etc/alternatives/go
lrwxrwxrwx 1 root root 25 Apr  1  2019 /etc/alternatives/go -> /usr/lib64/go/1.11/bin/go
➜  ~ ll /usr/lib64/go/
total 0
drwxr-xr-x 1 root root 46 Aug 13 15:00 1.11
drwxr-xr-x 1 root root 46 Sep  1 07:47 1.12
➜  ~ 

Thanks

Right now, users are expected to edit .alt.toml themselves. This is pretty crappy.

Users should be able to do this from the command line with decent validation (in case they screw up the command or version).

We could even give them a menu kind of like the one from alt scan ... so that they can choose a version.

Steps to reproduce

1. Add $HOME/.local/alt/shims to your PATH

2. Define a command in ~/.config/alt/defs.toml

   [node]

3. Make sure that you have no .alt.toml file for alt to pick up

4. Run alt exec node

alt will enter a strange loop where it will exec itself over and over again recursively.

This happens because alt tries to exec the command name when it doesn't find a binary

I've gotten pretty used to calling alt use with a version. Something like alt use node 10. This works really well when I have a version. If I want to switch to the system version of a command, I need to go through the menu because there's no shortcut for that.

Problem

alt exec echo --version
alt-exec

Expected behaviour

alt exec echo --version
--version

It seems like alt interprets some flags when they're passed to exec. This is probably an incorrect usage of clap

Clap support generating shell completion for apps. I believe that this would make alt a whole lot more usable since users will no longer need to remember command names and flags.

Documentation: https://docs.rs/clap/2.32.0/clap/struct.App.html#method.gen_completions

Steps to reproduce

mkdir -p /tmp/alt-use-crash
cd /tmp/alt-use-crash
alt def bash phony /usr/bin/bash
alt use bash phony

thread 'main' panicked at 'failed to read use file: Os { code: 21, kind: Other, message: "Is a directory" }', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: alt::use_file::load
  10: alt::cli::run
  11: alt::main
  12: std::rt::lang_start::{{closure}}
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: std::rt::lang_start_internal
  16: main

I think that this has to do with environment variables. I think that things get funny in some cases.

Example:

https://travis-ci.org/dotboris/alt/jobs/447509854#L655

---- config::tests::home_dir_should_default stdout ----
thread 'config::tests::home_dir_should_default' panicked at 'assertion failed: `(left == right)`
  left: `"/path/to/phony/home"`,
 right: `"/.config/alt"`', src/config.rs:35:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Currently, users are expected to:

1. Setup a rust dev environment (with cargo)
2. Build the code from source
3. Add shims to directory to PATH
4. Create the definitions file defs.toml

Ideally, we need something that requires the user to run the least number of steps while not being a maintenance nightmare.

Currently, alt use ... only supports picking a version.

In some cases, I might have previously selected a version for a command and then no longer want to specify any version at all.

I should be able to turn back to using the system version.

This is pretty minor, but it's a little bit of UX that can make things nicer for the user

Steps to reproduce

1. Run alt use {some-command} multiple times
2. Notice how the items change order from one run to another

I just ran a release (https://github.com/dotboris/alt/actions/runs/3867396110) and it coughed up about 20 deprecation warnings. This tells me that this repo is due for some CI maintenance.

Things to address (add to list as you find stuff):

• Node version update
• set-output

Hello,

OS: ubuntu 18

I have downloaded the .deb file from https://github.com/dotboris/alt/releases/tag/v1.2.0 and install it with the apt command.
A warning message is shown when finishing as below. I think it's because I log in as root.

Download is performed unsandboxed as root as file '/root/alt_1.2.0_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

This is a warning, so I just ignore it.

I try to config the multiple version of python. And it works.

I build 3 different versions of llvm and add the bin dir to the PATH. (I do not run command make install on them)

However, alt doesn't work on the llvm .

I'm curious that won't alt works on the software make and build by the source code?

Thanks for your help.
Looking forward to your reply.

A user on reddit reported that they can't install alt: https://www.reddit.com/r/commandline/comments/94s22n/i_just_released_a_tool_for_switching_between/e3zz18b/

They get the following error:

sh: 2: set: Illegal option -o pipefail

I've done some digging and it turns out that ubuntu uses dash as the sh shell. It seems like dash doesn't support the pipefail option.

Problem

Currently, alt is installed using a curl ... | bash one-liner. This is not really acceptable. It works, but it's not a good solution.

There are a few problems with this:

• curl ... | bash is super shady. A lot of people are not fond of installing packages using this.
• There's no good update mechanism. Updating can be done by just re-running the installer
• There's no easy / official uninstall method
• The script doesn't support all platforms (#31)
• No signing / verification of packages

Solution

The rough idea is to make it so that people can install alt using their system package manager. This is really a two part solution:

1. Build a package
2. Push that package to a repository

This something that should be CI driven as much as possible. The best would be to have all of this done automatically when a new version is pushed.

Platforms support

What follows is a rough list of platforms that we want to support. This list doesn't cover everything. It covers what I currently use and what I current use and need.

• OSX
• Debian and Friends
• Arch linux

References

• The rust cli working group is working on best practices for this https://github.com/rust-lang-nursery/cli-wg/issues/8
• Current recommendation for packaging cli apps https://rust-lang-nursery.github.io/cli-wg/tutorial/packaging.html

Steps to reproduce

$ env RUST_BACKTRACE=1 PATH="$PATH:/some/bs" alt scan something
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  10: <&'a mut I as core::iter::iterator::Iterator>::next
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: alt::scan::path_suffix::scan
  13: alt::scan_cmd::run
  14: alt::cli::run
  15: alt::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
  18: __rust_maybe_catch_panic
  19: std::rt::lang_start_internal
  20: main

This is an edge case, but it should be dealt with.

Not sure why this is happening. I've commented them out https://github.com/dotboris/alt/blob/master/.travis.yml#L33

For a little while now, every time I've tried to review a PR from dependabot, the CI fails. Something is clearly broken in a subtle way but I'm not sure what.

In my context, I mostly care about OSX since M1 & M2 chips are a thing but supporting ARM on linux is also a fine idea.