Cannot use tools with Aftman when Foreman is already managing them

[vocksel]

I have some projects that use Foreman, and when trying to install the same tools via Aftman I run into issues where Foreman is still trying to invoke those tools.

Here's my aftman.toml:

# This file lists tools managed by Aftman, a cross-platform toolchain manager.
# For more information, see https://github.com/LPGhatguy/aftman

# To add a new tool, add an entry to this table.
[tools]
luau-lsp = "JohnnyMorganz/luau-lsp@1.21.0"
rojo = "rojo-rbx/rojo@7.3.0"
selene = "kampfkarren/selene@0.25.0"
stylua = "JohnnyMorganz/StyLua@0.18.0"
wally = "UpliftGames/wally@0.3.2"

And after running aftman install, attempting to run wally init results in the following:

➜  camera-shaker git:(wally) wally init
'wally' is not a known Foreman tool, but Foreman was invoked with its name.

To use this tool from /Users/marin/Code/camera-shaker, declare it in a 'foreman.toml' file in the current directory or a parent directory.

Available Tools:

➜  camera-shaker git:(wally) 

Is this something that Aftman could provide support for? Or is this ultimately an issue with Foreman that would need to be patched? I'm hoping for the former, because I don't expect Foreman to receive any special support to not conflict with Aftman.

I'm currently torn on switching to Aftman because I have several projects still using Foreman, and there will continue to be projects owned by Roblox and other authors that won't be ported to Aftman.

[LPGhatguy]

This is a tough one to resolve because it's entangled with your system's PATH resolution.

If a tool is managed by Aftman and it's ahead in your PATH, that tool will always try to invoke the Aftman copy.

It'd be handy to fall through to other tools when the Aftman version is not managed by Aftman. I can think of a couple options for how we could try to do that:

• Parse the system PATH and fall through to the next executable found, if possible. This might be very tricky to get right across platforms but would provide the best experience, maybe at the expensive of performance. Tools like Bash keep caches around to make these lookups fast and we wouldn't have that.
• Special case looking for a Foreman-managed tool. This might not be so bad; we know where Foreman installs stuff. Users would have to put Aftman ahead of Foreman, but then Aftman could attempt to fall back when a tool isn't recognized.

[LastTalon]

For reference, I've encountered the same thing with cargo installed tooling as well. Depending on path order it can be tricky to get the right tool from different places.

A big part of the issue with foreman/aftman is that it leaves an executable in place all the time by necessity so that project switching can happen.

One additional option could be to add an additional layer of indirection with aftman, where the called aftman process exports an additional binary into the PATH when it has a binary to use for that project, then whether or not it does that, execs the name of the called tool. This would allow the system's normal path resolution and caching to happen, but aftman would need to be slightly more aware, but would have the advantage that it can be an aftman-only fix as well, as long as aftman is resolved first in your PATH.

[LPGhatguy]

I think this is probably too tricky to get right with the current way that Aftman works. For the time being, I'm going to close this as something I'm not considering for now.