Slightly wrong compatibilitytools.d searching?

[admalledd]

Per https://github.com/ValveSoftware/Proton/blob/proton_3.16/Makefile :: install directive, and the variable at the top for calculating the STEAM_DIR the correct/another search path for local builds seems to be $HOME/.steam/root/compatibilitytools.d

$HOME/.steam/root for me on one machine a symlink back to .steam while the other points as currently expected to $HOME/.steam/steam

Not sure of how you want to tweak get_custom_proton_installations() to handle that wonky-ness else I would do a PR. Hacky thought below:

if not os.path.isdir(comp_root):
    #try again at path used by proton's make install
    comp_root = os.path.join(os.environ['HOME'],'.steam','root','compatibilitytools.d')
    if not os.path.isdir(comp_root):
        return []

[admalledd]

Further reading of the $HOME/.steam/steam.sh on both my (ubuntu 18.04) machines indicates that maybe the correct thing is that there is a difference between steam's data root directory and the rest of steam's configurations.

It seems this file is installed/made by steam and not my package manager, right? Someone on non-debian derived able to check what the symlink(s) of $HOME/.steam/root point at, if anything?

Relevant lines from the steam.sh launcher script:

# We use ${HOME%/}/.steam for bootstrap symlinks so that we can easily
# tell partners where to go to find the Steam libraries and data.
# This is constant so that legacy applications can always find us in the future.
STEAMCONFIG="${HOME%/}/.steam" # Drop tailing slash in home folder if it exists.
PIDFILE="$STEAMCONFIG/steam.pid" # pid of running steam for this user
STEAMBIN32LINK="$STEAMCONFIG/bin32"
STEAMBIN64LINK="$STEAMCONFIG/bin64"
STEAMSDK32LINK="$STEAMCONFIG/sdk32" # 32-bit steam api library
STEAMSDK64LINK="$STEAMCONFIG/sdk64" # 64-bit steam api library
STEAMROOTLINK="$STEAMCONFIG/root" # points at the Steam install path for the currently running Steam
STEAMDATALINK="`detect_steamdatalink`" # points at the Steam content path
STEAMSTARTING="$STEAMCONFIG/starting"

Note that detect_steamdatalink is where steamapps always lives from my tracing/debugging. But the runtime, compat tools and so on live in $STEAMCONFIG/root (again, requires confirmation from other systems). The data link seems to resolve in one of three ways (two seem Valve internal only?):

1. : this is if steam is launched in development mode and a "steam_dev.cfg" is found. Likely for valve steam client developers on local machines.
2. $STEAMCONFIG/steambeta if you are somehow logged into the "beta/testing" steam content universe. This is different from the steam-client-beta and so on. From what I can glean from files this is most likely valve's internal testing content universe?
3. $STEAMCONFIG/steam default if neither dev nor beta type apply. Note that this path can also be a symlink. What fun!

Note that in my system where I have .local/share/Steam/... that steam seems to auto-create a symlink tree at .steam so that paths such as all below resolve:

• $HOME/.steam/steam for where app_root lives, always contains the SteamApps/steamapps folder. (case insensitive! STEAMAPPS is also valid, but who would do such a thing to us poor tool developers?)
• $HOME/.steam/root for where to find things such as compatibilitytools.d, ubuntu12_32, and other non-app resources.

Of course, this is me trying to use strace, gdb, and reading the scripts/installs I have which are only ubuntu/debian based. I once again ask if anyone on arch/fedora or whatever else to see if this looks "the same" ish?

[Matoking]

On my Arch system, both ~/.steam/steam and ~/.steam/root point to ~/.local/share/Steam. That directory in turn contains compatibilitytools.d, steamapps and pretty much anything else.

[admalledd]

That sounds like it should be compatible with the assumptions/learnings above for how to process things. Does PR #5 work/give a valid paths for you still? If so, it sounds like the proper processing is what is above.

[Matoking]

I installed Kubuntu 18.04 on a VM to double-check, and the Steam paths are indeed a bit wonky.

In the long term, it probably makes sense to ditch steam_root and steam_path path parameters and instead passing a SteamPath named tuple or something similar that contains a path to each relevant directory (eg. compatibilitytools.d, appcache, config, ubuntu12_32) so that we don't have to guess which of the two path parameters each function requires.

[Matoking]

The fix to this issue was pushed to master alongside the fix to #3.