Restructuring of folders/links

[rarkins]

Today we see paths like this:

/usr/local/helm/3.7.1
/usr/local/dotnet
/home/ubuntu/.gem-global/bin
/home/ubuntu/.gem/ruby/3.0.0/bin
/usr/local/ruby/3.0.3/bin
/home/ubuntu/.cargo/bin
/usr/local/rust/1.57.0/bin
/usr/local/go/1.17.4/bin
/go/bin
/usr/local/elixir/1.13.0/bin
/home/ubuntu/.npm-global/bin
/usr/local/yarn/1.22.17/bin
/home/ubuntu/.local/bin
/usr/local/python/3.10.0/bin
/usr/local/poetry/1.1.12/bin
/usr/local/pnpm/6.23.1/bin
/usr/local/php/7.4.26/bin
/usr/local/node/14.18.2/bin
/usr/local/java/11.0.13+8/bin
/usr/local/gradle/6.9.1/bin
/usr/local/composer/2.1.14/bin
/home/ubuntu/bin
/home/ubuntu/bin
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Can we restructure how we install so that it can be like this?

/home/ubuntu/bin
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

By this I'm hoping what can happen is that every time install-tool installs a version of a too, it symlinks it to /usr/local/bin or /home/ubuntu/bin.

e.g. install-tool npm 8.0.0 might install it into /home/ubuntu/.npm-global/bin but then there's be a symlink from /home/ubuntu/.npm-global/bin/npm to /home/ubuntu/bin/npm.

If we don't have to think about paths and dynamic ENV injection then wouldn't it be much easier to know what's installed?

[viceice]

Sounds good, but i prefer our shell wrapper and use some fixed files to read appropriate env

[rarkins]

Are there advantages to having ~20 dirs in the $PATH though? I'm not sure which bits of what I want are conflicting with what you wrote

[viceice]

i now go the symlink path, should work for root and non-root for node tools.

[rarkins]

Do you want a separate issue for other tools, so we have something to track?

I think any that we allow runtime install for should be symlinked into the shared bin folders, because otherwise our path will keep growing and growing.

Here's latest renovate/renovate for reference:

/usr/local/dotnet
/home/ubuntu/.gem-global/bin
/home/ubuntu/.gem/ruby/3.0.0/bin
/usr/local/ruby/3.0.3/bin
/home/ubuntu/.cargo/bin
/usr/local/rust/1.57.0/bin
/usr/local/go/1.17.4/bin
/go/bin
/usr/local/elixir/1.13.0/bin
/home/ubuntu/.npm-global/bin
/home/ubuntu/.local/bin
/usr/local/python/3.10.0/bin
/usr/local/gradle/6.9.1/bin
/home/ubuntu/bin
/usr/local/dotnet
/home/ubuntu/.gem-global/bin
/home/ubuntu/.gem/ruby/3.0.0/bin
/usr/local/ruby/3.0.3/bin
/home/ubuntu/.cargo/bin
/usr/local/rust/1.57.0/bin
/usr/local/go/1.17.4/bin
/go/bin
/usr/local/elixir/1.13.0/bin
/home/ubuntu/.npm-global/bin
/home/ubuntu/.local/bin
/usr/local/python/3.10.0/bin
/usr/local/gradle/6.9.1/bin
/home/ubuntu/bin
/home/ubuntu/bin
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

[rarkins]

Would it be cleaner to put everything in /usr/local/buildpack/ and /home/ubuntu/buildpack/? Then add /usr/local/buildpack/bin and /home/ubuntu/buildpack/bin to PATH

[rarkins]

jb and composer are the other two tools we support for runtime install today

[viceice]

mostly done #216

[viceice]

Would it be cleaner to put everything in /usr/local/buildpack/ and /home/ubuntu/buildpack/? Then add /usr/local/buildpack/bin and /home/ubuntu/buildpack/bin to PATH

Sure, we can do this. will be a breaking, as we need to update ENV PATH=... in Dockerfile

[rarkins]

No breaking change if we stick to /usr/local/bin and /home/user/bin?

[viceice]

yes

[rarkins]

Perhaps not worth it then. Can we nest actual installs inside a buildpack folder though?

[viceice]

yes, thats possible.

[viceice]

Can do the refactoring after #218