Add options to manually specify the path of various dependencies

[zany130]

System Information

• SteamTinkerLaunch version: steamtinkerlaunch-v14.0.20240904-1
• Distribution: Bazzite

Feature Description

As I mentioned before steamtinkerlaunch is not finding dependencies installed with brew like peres for example.

It turns out this is because brew is only added to the PATH on interactive sessions (i.e., a terminal).
It is not in the path when you run steamtinkerlaunch so therefore it can't find it.

I was thinking maybe we can add the homebrew paths somewhere in the STL code, but I think that's better left to the user.

Instead it may be a good idea to allow the user to specify where dependices like peres are stored.
This is already done for some dependencies, such as boxtron, Roberta, notify-send, and netstat, in the global menu.

We could extend this list to include all dependencies of steamtinkerlaunch (or maybe have another menu as it may get rather long and unwieldy)

The user may for example, have a locally built game scope or mangohud they want to use instead of the one in there system's PATH

I have no idea how easy this would be to implement, but conceptually, it sounds good. I will try to take a look at it soon.

Of course if any has any ideas or wants to take a shot at it please do feel free!

[sonic2kk]

I don't think this is necessary, I think SteamTinkerLaunch should stick to being able to find things that are on PATH. If Homebrew does not add things to PATH globally, then this should be manually edited by the user.

I understand the rationale but the solution is for things to be on the path, so that all programs can find it. It seems really strange that Homebrew would not add things to path normally, and I couldn't find any information about this online (although the vast majority of Homebrew information is about macOS, where installed commands are on PATH to my understanding).

The dependencies that we do allow the user to specify paths for are more general tools than commandline utilities. The tools we allow to specify paths for are tools that would not normally be on PATH, for example Boxtron. Things like notify-send can be specified because you might want to use an alternative notification service.

The user may for example, have a locally built game scope or mangohud they want to use instead of the one in there system's PATH

These should be on PATH though, they could be added manually to PATH or put into a local binary path that is on the PATH variable already (such as ~/.local/bin). Although note that the path to MangoHUD can be specified I think, I can't remember the rationale for this but I think it is more of an "insurance" thing as at the time MangoHUD had strange issues.

I have no idea how easy this would be to implement, but conceptually, it sounds good. I will try to take a look at it soon.

It would not necessarily be difficult to implement, but this is not really a feature imo. This is a workaround to a package manager issue (Homebrew, in this case).

It would be pointless to install a dependency via Homebrew if applications which want to use that dependency could not use it, so surely there should be a way to add them to PATH on Linux.

---

After digging more just after posting this, I found this article by DigitalOcean (iirc some sort of serverless provider) that has a command which has to be ran in order for Homebrew to add packages to your PATH.

[zany130]

The main problem I see with this is that it will definitely clutter the global menu more than it already is, and it will grow each time we add a dependency.

And I agree the examples I gave are not the same. I'm guessing we could implement this in the same way, though.

As for brew not being in the PATH. It is when you run echo $PATH in a terminal but not when STL checks the path. I have no idea why this is, but I heard from another Bazzite user that this is "expected behavior." (BTW I did try manually exporting the homebrew paths in my .bashrc, but the homebrew install script should already handle the path for you)

I know, for example, https://github.com/bpozdena/OneDriveGUI, you have to manually specify the path to the brew onedrive binary in the settings.

but again, we go back to that being only one dependency and several here I can see it getting messy being able to configure all the paths and in most case it should not be needed/ is easier to have things in the PATH

So I can see why you would see this more as a fix for the brew problem vs an actual feature request

[sonic2kk]

As for brew not being in the PATH. It is when you run echo $PATH in a terminal but not when STL checks the path. I have no idea why this is, but I heard from another Bazzite user that this is "expected behavior." (BTW I did try manually exporting the homebrew paths in my .bashrc, but the homebrew install script should already handle the path for you)

I know, for example, bpozdena/OneDriveGUI, you have to manually specify the path to the brew onedrive binary in the settings.

That is really strange. If you run SteamTInkerLaunch from this terminal session, can it find the Homebrew path? In that case surely it should take the variable from the environment. For example if you were to run these commands, SteamTinkerLaunch would pick up the updated PATH value for that session with that variable set only.

$ export PATH="${PATH}:/home/username/test"
$ steamtinkerlaunch settings

If you run this, the SteamTinkerLaunch log will show the /home/username/test path in the PATH variable it picked up. But if you run from Steam, it will not (and any other terminal session also won't have that path, since export is for that session only).

Is this perhaps a configuration problem with Steam? Is Bazzite using an unofficial repackaging of Steam i.e. the Flatpak that doesn't have access to the Brew paths?

I would really prefer not to add workarounds for finding things that should be on PATH.

[zany130]

Is this perhaps a configuration problem with Steam? Is Bazzite using an unofficial repackaging of Steam i.e. the Flatpak that doesn't have access to the Brew paths?

I don't think so.

From what I understand bazzite uses the steam package from fedora.

That is really strange. If you run SteamTInkerLaunch from this terminal session, can it find the Homebrew path? In that case surely it should take the variable from the environment. For example if you were to run these commands, SteamTinkerLaunch would pick up the updated PATH value for that session with that variable set only.

Yes, if I run steamtinkerlaunch settings from the terminal, it will find the brew path.

echo $PATH
/home/linuxbrew/.linuxbrew/bin /home/linuxbrew/.linuxbrew/sbin /home/zany130/stl/prefix SETUVAR SETUVAR  /home/zany130/.atuin/bin /home/zany130/.cargo/bin /usr/local/bin /usr/bin /bin /usr/local/sbin /usr/sbin /sbin /home/zany130/.local/bin /home/zany130/bin /home/linuxbrew/.linuxbrew/opt/binutils/bin /home/zany130/.local/share/JetBrains/Toolbox/scripts

steamtinkerlaunch settings


cat /dev/shm/steamtinkerlaunch/vars-in.txt | grep "PATH"
GOLDWARDEN_SOCKET_PATH=/home/zany130/.var/app/com.quexten.Goldwarden/data/goldwarden.sock
INFOPATH=/home/linuxbrew/.linuxbrew/share/info
PATH=/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/home/zany130/stl/prefix:SETUVAR SETUVAR :/home/zany130/.atuin/bin:/home/zany130/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/zany130/.local/bin:/home/zany130/bin:/home/linuxbrew/.linuxbrew/opt/binutils/bin:/home/zany130/.local/share/JetBrains/Toolbox/scripts
VORTEXDOWNLOADPATH=/home/zany130/.config/steamtinkerlaunch/vortex/downloads
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0

But when ran from Steam the path is

PATH=/var/home/zany130/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/bin:/var/home/zany130/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin:/var/home/zany130/.local/share/Steam/ubuntu12_32/steam-runtime/usr/bin:/home/zany130/.atuin/bin:/home/zany130/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/zany130/.local/bin:/home/zany130/bin:/home/linuxbrew/.linuxbrew/opt/binutils/bin:/home/zany130/stl/prefix:/home/zany130/.local/share/JetBrains/Toolbox/scripts

notice
/home/linuxbrew/.linuxbrew/opt/binutils/bin
is still in the path when ran from steam but not

/home/linuxbrew/.linuxbrew/bin
and
/home/linuxbrew/.linuxbrew/sbin

[sonic2kk]

From testing it does seem like there is some weirdness about how Steam can detect PATH. I remember something related to this come to think of it with ProtonUp-Qt and Steam launch option's not being able to find the local install at i.e. ~/stl/prefix.

I'll do some more testing, my guess is that paths have to be set elsewhere (maybe in .profile?)

[sonic2kk]

It would be good to check where /home/linuxbrew/.linuxbrew/opt/binutils/bin is appended and what this contains, and why it is different from the other paths listed.

[sonic2kk]

I thought some more about this, and I guess it is not really viable to get Steam to pull from an updated PATH variable. But on the other hand, introducing for example the Homebrew paths opens up a can of worms. Then again, we already do this on Steam Deck for the $HOME/stl/deps/usr/bin path to my knowledge (not that this is something I would want to limit to SteamOS).

I am thinking we should have a way to inject custom paths that SteamTinkerLaunch can load, which in the context of this issue I think is more or less what you are asking. The trouble is doing this in a clean way and a way that would actually be helpful. I think hardcoding Homebrew paths is not the right solution on its face, but I think I was mistaken and that you are correct that we need a way to get SteamTinkerLaunch to load alternative dependency paths.

Maybe that's as high level as we need it to be, a list of "alternative dependency paths". I am not sure where would be best to specify this though. Initially I considered the global.conf, but ideally we would want this to either be pre-configured by distributions (such as Bazzite) or something a user would have good insight to tinker with, and I'm not sure it makes "sense" from an end-user perspective to have this in the global.conf.

Having it there would make it easier to expose on the GUI though. But I have no idea how we could expose such a thing on the Global Menu from a GUI perspective; a textbox is not great, and we can't have a dynamic GUI with Yad or a multi-folder select thing. It would basically be limited to a textbox, since internally in the global.conf we would need to store it as something like EXTRADEPENDENCYPATHS="/home/gaben/.brew/whatever:/home" (comma-delimited since that would make it easier to append to the PATH variable).

Maybe we just don't need to put it on the GUI, or we can just expose it as a plain textbox.

I have not dug into the code to see how viable it would be to load these paths early, but I think it should be. I think we can read the global config before checking for dependencies, although we should keep in mind that we would want to load this on a separate code path for SteamOS or before steamdedeckt (or whatever SteamOS function modifies the PATH). We need to do this so that we don't end up modifying the path and then losing that modification when updating it for SteamOS, and also to make sure we don't write any duplicate paths (i.e. if we do load these on separate code paths, we don't want to load it early, and then load it again for SteamOS).

---

So in short, having thought more about it, this enhancement makes sense and should be doable, it's just a case of:

• What should we name it? Is something like "ALTERNATIVEDEPSPATHS" a good enough name?
• Should it go into the Global Config or perhaps live in a separate file? Ideally distributions like Bazzite would configure this so that SteamTinkerLaunch can load the dependency paths out of the box without user intervention in cases where this is not viable (like on Bazzite).
• Should this be exposed on the UI?
• Maybe other pitfalls I have not foreseen here.

So there are still some questions on my end on the best approach, but I am more open to this idea after thinking more about it. 😄

[zany130]

What if we had a file (or maybe we could just do this in the global config file just not exposed on the gui) where we can add a comma separated list of paths

By default this will contain the homebrew path and $HOME/stl/deps/usr/bin

Then just read from that file early in the code?

Do we really need to have $HOME/stl/deps/usr/bin only on steamos?

One problem I see adding homebrew to the path for STL is how would it handle a dependices being available through the system package manager AND through homebrew?

Homebrew doesn't use system packages and instead installs its own copies.

So for example I have systemd provided by homebrew and the system

Another example is wget

If we add homebrew to the path which wget will be used?

I think that's why homebrew is not added to the system path unless you're explicitly running an interactive shell

Though I think the path is read left to right so if you're system paths are first it should use those vs brew?