Use an updated version of ruby

In the terminal I’ve successfully installed rbenv, and ruby-build from GitHub, and I’ve modified my path and when I type ruby -v I get 3.0.0. But I can’t seem to find any way to coerce Glitch to respect my $PATH and use my version of ruby at /app/.rbenv/shims/ruby. It just always goes back to the one installed in /usr. I’ve tried doing it within Bundler, or directly, but no dice. Does anybody have an example or ideas of how to make this work?

Have you tried .bashrc??

Yes I’ve set my path in .bashrc, .bash_profile, and the .env file to no avail.

With export command? or alias?

Like I said in the terminal “ruby -v” reports just fine because the path is correct.

@youngchief_btw export PATH="$HOME/.rbenv/bin:$PATH"

Have you tried refreshing?

Of course! :slight_smile: it sounds like you think this should work, which is encouraging. I’ll dig around and see what I must not have linked up properly.

1 Like

it simply doesn’t seem the commands executed by glitch.json in install or start respect my path.

yep it’s actually at the top of /opt/watcher/app-types/, it forces PATH back to the variable $USER_PATH. :frowning:

But then the next-next thing it does in /opt/watcher/app-types/custom/ is to call read-env which would set up the PATH you set in .env, so shouldn’t it be okay?

Those are only set for the child process, it doesn’t let you change the env vars on itself. It all makes sense from a security perspective I think. I found a solution by sym linking to my binaries from ~/bin

Actually, maybe putting it in .env would work and I overlooked it :).

But I prefer my way because any remix will still work since my symlinks won’t get stripped out.

You could also include a script in your project to set up the symlinks.
That way you tell people in your that they should run the script as part of setup

I agree with that, but with subsequently launching the app as a child process, that all should end up working in the end.

actually I don’t believe it does launch a child process, it just evals the START_CMD, but it also seems to export all the .env vars directly via source .env, so it does seem like putting PATH= in the .env file would work and I must’ve not tested that thoroughly. But in any case I’m not going to spend any further time investigating it for now :slight_smile:

no need for a script…that’s why the symlinks are preferable to the .env IMO