Hi all,
I have written an ugly (at least at the current stage) but probably(?) useful shell script jvc.sh for Julia installation and version management.
Perhaps you can consider jvc.sh as a heavy version of jill.sh or something similar to jill.py but in shell. If you are already a user of jill.py, this script might not be really useful for you since it only supports Linux and MacOS.
There are a few motivations:
- I want to reduce dependency as much as possible (e.g., I might not prefer to install a python script using pip first to install Julia)
- Julia is evolving rather fast and I guess most people are eager to try the new version. (e.g., 1.6.1 is released merely 1 month later after 1.6.0)
- I would also like to have a fast version switching locally to check possible different behaviors. (e.g., I do have some experience where packages fail to work after a patch…)
- It turns out that perhaps I would like to have something similar to nvm-sh.
- IonCLI.jl would probably be a better option in the future if the binary size can be reduced. Also the original motivation is on package management. See [ANN] IonCLI: your package manager and more in terminal
Install JVC and configure your paths:
git clone
to your preferred path (e.g.~/.jvc)
git clone https://github.com/songxianxu/jvc ~/.jvc
- In your shell config file, e.g.,
.bashrc
or.zshrc
, add the following environment variables
export PATH=$PATH:~/.jvc:~/.local/bin/jvc/
The second path~/.local/bin/jvc/
is the where jvc search julia symlink, feel free to change it, however, you would also need to change it in.jvcrc
accordingly. (I would try to avoid modifying other’s rc files)
If you want to change the julia tarball download folder or installation folder, you can change the environment variables in .jvcrc
. Mac users can uncomment the section for Mac in .jvcrc
Note: frankly speaking, .jvcrc
should not even exist in the first place as it is just some environment variables. It is used to store and modify UPSTREAM_NAME locally. I am thinking of get rid of the .jvcrc
file in the future.
Explanation of these environment variables:
JULIA_DOWNLOAD_DIR
: where julia tarball is downloadedJULIA_INSTALL_DIR
: where julia is installedJULIA_SYMLINK_DIR
: where julia symlink is storedUPSTREAM_NAME
: name of upstream, no manually invention required. Can be adjust usingjvc upstream
Basic usage
Install Julia
jvc install # default install current stable verision (Now 1.6.1)
jvc install 1 # will install the stable major version 1 which is 1.6.1
jvc install 1.5 # will install 1.5.4
jvc install 1.5.4
jvc install 1.6.0
jvc install 1.6.0-rc1
jvc install lts # 1.0.5
jvc install rc # 1.6.0-rc3
jvc install nightly
jvc nightly
jvc installed # list all installed julia version by checking JULIA_INSTALL_DIR
Download tarball only
jvc download [version]
# Similar logic to install
Load/unload symlink for specific version
jvc load 1.5.3
to make julia-1.5.3
available
jvc unload 1.5.3
to remove julia-1.5.3
unavailable (this is not to uninstall julia 1.5.3, just remove the symlink)
jvc loaded
show all loaded version
jvc purge
unload all loaded version in case you have loaded too many:). julia
symlink will still remain.
**Switch julia symlink **
jvc switch 1.5.3
to make julia
symlink use julia 1.5.3
Show status of julia installation and loaded
jvc status
Show installed version, loaded version, downloaded version and upstream
Search for a version
jvc search [version]
Query all available version exist
jvc avail/available
jvc avail all #including rc and beta
Uninstall Julia
jvc remove
No version info is needed. A list of installed version will be shown and you will need to manually key in the version to uninstall (for safety).
Julia version migration (keep track of Project.toml and Manifest.toml)
jvc migrate 1.5 to 1.6
This will simply cp the Project.toml
和 Manifest.toml
in the corresponding version environment folders`
Change the upstream for downloading
jvc upstream
Perhaps you will want to change the upstream for fast downloading.
The information is stored in upstream.conf
.
Side notes
- It is the first time for me to write such a lengthy shell script and there are too many places I should improve on but yet I have not started to work towards on. I have referred from nvm-sh and jill.sh during the work.
- Initially, I would like to call it
jvm
but it probably coincides with java virtual machine? - Suggestions are welcome and hopefully someone can kick me out of the comfort zone (simply because it is working now…but some of the utilities are not sustainable as far as I can see).
- The MacOS compatibility still requires further testing as I do not have a MacOS device.
- Many thanks @JohnnyChen94 for useful feedback and discussions.
Some related projects: