psi-jack/zimfw
1
0
Fork 0
mirror of synced 2024-06-28 19:31:08 -04:00
Code Issues Releases Wiki Activity
zimfw/src/tools/install.zsh.erb

21 lines
491 B
Plaintext
Raw Normal View History

Add a plugin mechanism \o/ This is a major change, where Zsh modules/plugins are not git submodules in the Zim repo anymore, but customized and installed separately as individual repositories. The discussion about this started more than 2 years ago in #88. Closes #299. This will allow contributors' modules to live in their own repositories. Closes #33, closes #138, closes #262, closes #277, closes #281. Some discussion topics that I think are worth considering before merging this: - [ ] Reduce the Zim "core" to a single file? - [ ] Simplify installation? With an installation script? (See #182) - [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`? (See #288) - [ ] Rerun the Eriner/zsh-framework-benchmark? I suggest we create individual GitHub issues/PRs to start the separate discussions. The current code has what, up to this point, I considered to be the best balance between simplicity, execution speed and number of files. One measured decision was to make the initialization of modules depend only on the `':zim' modules` style, keeping it as fast as possible. The `':zim:module' module` style is used to install, update and clean the modules, all operations that happen after the user got his as-blazing-fast-possible shell prompt. Even though I didn't care much about making install or update fast, `xargs` has a nice feature of allowing commands to be executed in parallel with `-P`. I took advantage of that. I've also worked on making the `zimfw` utility give the user some nice (while still minimalistic) output. Also I'm suggesting this as the new name for the `zmanage` tool, since `zimfw` does not shadow the `zim` wiki tool. I strongly recommend you install this from scratch in a separate directory, instead of checking out `develop` in your current Zim installation repo.
2019-01-07 18:25:34 -05:00
# This runs in a new shell
Zim script in a single file \o/ Also moved the templates out of this repository, and into the zimfw/install repo. This is a second big change after introducing the plugin mechanism. This makes installation and upgrading of Zim straightforward. Maybe the most important aspect of having the script in a single file is not having to manage "git repos inside git repos" (see #297), since the single file exists by itself and is not version-controlled (with git). I've implemented a two-stage sourcing of the file, so most of the file is only sourced when needed (namely when calling `zimfw` with any action other than `login-init`). The two-stage process is designed to avoid compromising the startup speed, which is our top priority. In an effort to help making the script maintainable, I've broken it into small ERB templates. This also adds the ability to pre-process the Zsh code with Ruby code. To build the script, use `make`.
2019-01-22 19:40:43 -05:00
DIR=${1}
URL=${2}
Add a plugin mechanism \o/ This is a major change, where Zsh modules/plugins are not git submodules in the Zim repo anymore, but customized and installed separately as individual repositories. The discussion about this started more than 2 years ago in #88. Closes #299. This will allow contributors' modules to live in their own repositories. Closes #33, closes #138, closes #262, closes #277, closes #281. Some discussion topics that I think are worth considering before merging this: - [ ] Reduce the Zim "core" to a single file? - [ ] Simplify installation? With an installation script? (See #182) - [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`? (See #288) - [ ] Rerun the Eriner/zsh-framework-benchmark? I suggest we create individual GitHub issues/PRs to start the separate discussions. The current code has what, up to this point, I considered to be the best balance between simplicity, execution speed and number of files. One measured decision was to make the initialization of modules depend only on the `':zim' modules` style, keeping it as fast as possible. The `':zim:module' module` style is used to install, update and clean the modules, all operations that happen after the user got his as-blazing-fast-possible shell prompt. Even though I didn't care much about making install or update fast, `xargs` has a nice feature of allowing commands to be executed in parallel with `-P`. I took advantage of that. I've also worked on making the `zimfw` utility give the user some nice (while still minimalistic) output. Also I'm suggesting this as the new name for the `zmanage` tool, since `zimfw` does not shadow the `zim` wiki tool. I strongly recommend you install this from scratch in a separate directory, instead of checking out `develop` in your current Zim installation repo.
2019-01-07 18:25:34 -05:00
REV=${4}
OPT=${5}
MODULE=${DIR:t}
Zim script in a single file \o/ Also moved the templates out of this repository, and into the zimfw/install repo. This is a second big change after introducing the plugin mechanism. This makes installation and upgrading of Zim straightforward. Maybe the most important aspect of having the script in a single file is not having to manage "git repos inside git repos" (see #297), since the single file exists by itself and is not version-controlled (with git). I've implemented a two-stage sourcing of the file, so most of the file is only sourced when needed (namely when calling `zimfw` with any action other than `login-init`). The two-stage process is designed to avoid compromising the startup speed, which is our top priority. In an effort to help making the script maintainable, I've broken it into small ERB templates. This also adds the ability to pre-process the Zsh code with Ruby code. To build the script, use `make`.
2019-01-22 19:40:43 -05:00
CLEAR_LINE="\033[2K\r"
Add a plugin mechanism \o/ This is a major change, where Zsh modules/plugins are not git submodules in the Zim repo anymore, but customized and installed separately as individual repositories. The discussion about this started more than 2 years ago in #88. Closes #299. This will allow contributors' modules to live in their own repositories. Closes #33, closes #138, closes #262, closes #277, closes #281. Some discussion topics that I think are worth considering before merging this: - [ ] Reduce the Zim "core" to a single file? - [ ] Simplify installation? With an installation script? (See #182) - [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`? (See #288) - [ ] Rerun the Eriner/zsh-framework-benchmark? I suggest we create individual GitHub issues/PRs to start the separate discussions. The current code has what, up to this point, I considered to be the best balance between simplicity, execution speed and number of files. One measured decision was to make the initialization of modules depend only on the `':zim' modules` style, keeping it as fast as possible. The `':zim:module' module` style is used to install, update and clean the modules, all operations that happen after the user got his as-blazing-fast-possible shell prompt. Even though I didn't care much about making install or update fast, `xargs` has a nice feature of allowing commands to be executed in parallel with `-P`. I took advantage of that. I've also worked on making the `zimfw` utility give the user some nice (while still minimalistic) output. Also I'm suggesting this as the new name for the `zmanage` tool, since `zimfw` does not shadow the `zim` wiki tool. I strongly recommend you install this from scratch in a separate directory, instead of checking out `develop` in your current Zim installation repo.
2019-01-07 18:25:34 -05:00
if [[ -e ${DIR} ]]; then
# Already exists
return 0
fi
Zim script in a single file \o/ Also moved the templates out of this repository, and into the zimfw/install repo. This is a second big change after introducing the plugin mechanism. This makes installation and upgrading of Zim straightforward. Maybe the most important aspect of having the script in a single file is not having to manage "git repos inside git repos" (see #297), since the single file exists by itself and is not version-controlled (with git). I've implemented a two-stage sourcing of the file, so most of the file is only sourced when needed (namely when calling `zimfw` with any action other than `login-init`). The two-stage process is designed to avoid compromising the startup speed, which is our top priority. In an effort to help making the script maintainable, I've broken it into small ERB templates. This also adds the ability to pre-process the Zsh code with Ruby code. To build the script, use `make`.
2019-01-22 19:40:43 -05:00
[[ ${OPT} != -q ]] && print -n "${CLEAR_LINE}Installing ${MODULE} …"
Add a plugin mechanism \o/ This is a major change, where Zsh modules/plugins are not git submodules in the Zim repo anymore, but customized and installed separately as individual repositories. The discussion about this started more than 2 years ago in #88. Closes #299. This will allow contributors' modules to live in their own repositories. Closes #33, closes #138, closes #262, closes #277, closes #281. Some discussion topics that I think are worth considering before merging this: - [ ] Reduce the Zim "core" to a single file? - [ ] Simplify installation? With an installation script? (See #182) - [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`? (See #288) - [ ] Rerun the Eriner/zsh-framework-benchmark? I suggest we create individual GitHub issues/PRs to start the separate discussions. The current code has what, up to this point, I considered to be the best balance between simplicity, execution speed and number of files. One measured decision was to make the initialization of modules depend only on the `':zim' modules` style, keeping it as fast as possible. The `':zim:module' module` style is used to install, update and clean the modules, all operations that happen after the user got his as-blazing-fast-possible shell prompt. Even though I didn't care much about making install or update fast, `xargs` has a nice feature of allowing commands to be executed in parallel with `-P`. I took advantage of that. I've also worked on making the `zimfw` utility give the user some nice (while still minimalistic) output. Also I'm suggesting this as the new name for the `zmanage` tool, since `zimfw` does not shadow the `zim` wiki tool. I strongly recommend you install this from scratch in a separate directory, instead of checking out `develop` in your current Zim installation repo.
2019-01-07 18:25:34 -05:00
if ERR=$(command git clone -b ${REV} -q --recursive ${URL} ${DIR} 2>&1); then
if [[ ${OPT} != -q ]]; then
Zim script in a single file \o/ Also moved the templates out of this repository, and into the zimfw/install repo. This is a second big change after introducing the plugin mechanism. This makes installation and upgrading of Zim straightforward. Maybe the most important aspect of having the script in a single file is not having to manage "git repos inside git repos" (see #297), since the single file exists by itself and is not version-controlled (with git). I've implemented a two-stage sourcing of the file, so most of the file is only sourced when needed (namely when calling `zimfw` with any action other than `login-init`). The two-stage process is designed to avoid compromising the startup speed, which is our top priority. In an effort to help making the script maintainable, I've broken it into small ERB templates. This also adds the ability to pre-process the Zsh code with Ruby code. To build the script, use `make`.
2019-01-22 19:40:43 -05:00
print -P "${CLEAR_LINE}%F{green}✓%f ${MODULE}: Installed"
Add a plugin mechanism \o/ This is a major change, where Zsh modules/plugins are not git submodules in the Zim repo anymore, but customized and installed separately as individual repositories. The discussion about this started more than 2 years ago in #88. Closes #299. This will allow contributors' modules to live in their own repositories. Closes #33, closes #138, closes #262, closes #277, closes #281. Some discussion topics that I think are worth considering before merging this: - [ ] Reduce the Zim "core" to a single file? - [ ] Simplify installation? With an installation script? (See #182) - [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`? (See #288) - [ ] Rerun the Eriner/zsh-framework-benchmark? I suggest we create individual GitHub issues/PRs to start the separate discussions. The current code has what, up to this point, I considered to be the best balance between simplicity, execution speed and number of files. One measured decision was to make the initialization of modules depend only on the `':zim' modules` style, keeping it as fast as possible. The `':zim:module' module` style is used to install, update and clean the modules, all operations that happen after the user got his as-blazing-fast-possible shell prompt. Even though I didn't care much about making install or update fast, `xargs` has a nice feature of allowing commands to be executed in parallel with `-P`. I took advantage of that. I've also worked on making the `zimfw` utility give the user some nice (while still minimalistic) output. Also I'm suggesting this as the new name for the `zmanage` tool, since `zimfw` does not shadow the `zim` wiki tool. I strongly recommend you install this from scratch in a separate directory, instead of checking out `develop` in your current Zim installation repo.
2019-01-07 18:25:34 -05:00
fi
else
Zim script in a single file \o/ Also moved the templates out of this repository, and into the zimfw/install repo. This is a second big change after introducing the plugin mechanism. This makes installation and upgrading of Zim straightforward. Maybe the most important aspect of having the script in a single file is not having to manage "git repos inside git repos" (see #297), since the single file exists by itself and is not version-controlled (with git). I've implemented a two-stage sourcing of the file, so most of the file is only sourced when needed (namely when calling `zimfw` with any action other than `login-init`). The two-stage process is designed to avoid compromising the startup speed, which is our top priority. In an effort to help making the script maintainable, I've broken it into small ERB templates. This also adds the ability to pre-process the Zsh code with Ruby code. To build the script, use `make`.
2019-01-22 19:40:43 -05:00
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: Error%f\n${ERR}"
Add a plugin mechanism \o/ This is a major change, where Zsh modules/plugins are not git submodules in the Zim repo anymore, but customized and installed separately as individual repositories. The discussion about this started more than 2 years ago in #88. Closes #299. This will allow contributors' modules to live in their own repositories. Closes #33, closes #138, closes #262, closes #277, closes #281. Some discussion topics that I think are worth considering before merging this: - [ ] Reduce the Zim "core" to a single file? - [ ] Simplify installation? With an installation script? (See #182) - [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`? (See #288) - [ ] Rerun the Eriner/zsh-framework-benchmark? I suggest we create individual GitHub issues/PRs to start the separate discussions. The current code has what, up to this point, I considered to be the best balance between simplicity, execution speed and number of files. One measured decision was to make the initialization of modules depend only on the `':zim' modules` style, keeping it as fast as possible. The `':zim:module' module` style is used to install, update and clean the modules, all operations that happen after the user got his as-blazing-fast-possible shell prompt. Even though I didn't care much about making install or update fast, `xargs` has a nice feature of allowing commands to be executed in parallel with `-P`. I took advantage of that. I've also worked on making the `zimfw` utility give the user some nice (while still minimalistic) output. Also I'm suggesting this as the new name for the `zmanage` tool, since `zimfw` does not shadow the `zim` wiki tool. I strongly recommend you install this from scratch in a separate directory, instead of checking out `develop` in your current Zim installation repo.
2019-01-07 18:25:34 -05:00
return 1
fi
Reference in a new issue Copy permalink