Restructuring of folders/links #213
Comments
|
Sounds good, but i prefer our shell wrapper and use some fixed files to read appropriate env |
|
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 |
|
i now go the symlink path, should work for root and non-root for node tools. |
|
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 Here's latest |
|
Would it be cleaner to put everything in |
|
|
|
mostly done #216 |
Sure, we can do this. will be a breaking, as we need to update |
|
No breaking change if we stick to /usr/local/bin and /home/user/bin? |
|
yes |
|
Perhaps not worth it then. Can we nest actual installs inside a buildpack folder though? |
|
yes, thats possible. |
|
Can do the refactoring after #218 |
|
current path on full image: > docker run --rm -it renovate/renovate sh -c 'echo $PATH | tr ":" "\n"'
/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/.local/bin
/usr/local/python/3.10.1/bin
/home/ubuntu/.npm-global/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 |
|
We need to move tools below language:
This will allow installing the same version of |
|
ok, as long as there's no file name conflicts because that directory name is already used |
viceice
added
priority-3-normal
|
We should also make Versions installed by root should be protected, so user can't modify them. We also need to make We should write current tool version to |
|
I'm open for better paths for version files (#185) and env to an other folder, eg |
Do you have an overview for me why that is needed? when we need another version of npm we do: which in the end will just install npm in the needed version. If we want to do that, then we need to install both at the same time, like or should we install |
|
The last option was my idea. Those where required if we process multiple repo's who require different language version. Eg first repo needs node v16 and npm V8. Currently we would only install new node version and keep npm. Npm could have resolved peer deps to versions which don't support node v14, so later call can fail. Not sure if this really happens in npm, but there are other languages and tools where it will happen for sure. |
|
Ok, so we need to make this configurable. |
|
@viceice What tools that we currently have should be installed in a subfolder? Currently I can think of:
or is this not needed for certain parts? |
|
I'm not sure if there's a foolproof way to know when a tool is dependent on the underlying version of the language, or not. Perhaps we need the concept of defining the compatibility, e.g. major/minor/patch. Major compatibility means we'd e.g. want to yarn if the major version of node changed (e.g. 14 -> 16). Minor would mean not reinstalling Poetry if the minor version stayed the same (e.g. 3.8.0 -> 3.8.1). And "patch" can maybe mean "always reinstall" if any language difference (not sure if we have any?). |
|
We can make this as complex as we want, but maybe we have a way to provide a simple solution right now. My current approach enables each tool to determine on its own if and where it wants to be installed. |
|
Sure, my concern was just if we ended up with hugely bloated runtime images because tools kept being reinstalled every time there's a patch bump of the language |
|
Do you run the images for extended amounts of time? The only thing I can imagine is that you run Renovate for a bunch of repos and hey all require different node and npm versions. |
|
Right now the app and WhiteSource Renovate On-Premises essentially run indefinitely, but that might need to change if we bloat the containers too much at runtime |
|
Good to know, in that case we might need to think about how to solve this. |
|
So the >docker run --rm -it renovate/renovate sh -c 'echo $PATH | tr ":" "\n"' ─╯
/home/ubuntu/.cargo/bin
/home/ubuntu/.local/bin
/go/bin
/home/ubuntu/bin
/opt/buildpack/tools/python/3.11.1/bin
/home/ubuntu/.npm-global/bin
/home/ubuntu/bin
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/binI'm not sure if we can fix python and node global. I've now implemented a way for ruby to install bundler and cocoapods ruby minor version depended. eg Bundler v1.17.2 on Ruby v2.6.4: We probably should close this issue now and open new for the version dependend tools. We can maybe do it like bundler now. |
Today we see paths like this:
Can we restructure how we install so that it can be like this?
By this I'm hoping what can happen is that every time
install-toolinstalls a version of a too, it symlinks it to/usr/local/binor/home/ubuntu/bin.e.g.
install-tool npm 8.0.0might install it into/home/ubuntu/.npm-global/binbut then there's be a symlink from/home/ubuntu/.npm-global/bin/npmto/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?
The text was updated successfully, but these errors were encountered: