This repository has been archived by the owner on Mar 22, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit changes the current setup but does not add or remove anything major.
setup.sh
toscript.sh
:If the file is named
setup.sh
github uses that instead of using any user defined dotfile repo. In my case i have a dotfiles repo that adds my wakatime api key to wakatime config file. But due to the.devcontainer/setup.sh
file, it gets ignored which is kinda bothersome.script.sh
:For some reason installing rustup does not immediately load the
~/.cargo/bin
directory to path. Trying to source the.bashrc
/.zshrc
file exits the setup file for some reason.As such using the direct path to cargo and rustup works.Re-exporting the PATH var after adding cargo bin dir works.cargo-binstall
:For installing cargo-expand and cargo-edit, its faster to use
cargo-binstall
. cargo-binstall itself is easy to install using a one-liner shell script and installation of the cargo-plugins is also way faster as theres no need to compile the plugins.devcontainer.json
:Nothing major in it. It just moves the settings and extensions property inside
customizations.vscode
cause the devcontainer extension just screams the warnings otherwise.I have tried and tested the above configuration and have ensured it works. I've also considered replacing oh-my-zsh with
oh-my-posh
since features are nearly identical for both but oh-my-posh would work with other shells too in case necessary. But not sure wether that would be supported by the repo authors.