Prezto: Add an installation script

Created on 6 Aug 2012  Â·  26Comments  Â·  Source: sorin-ionescu/prezto

A one line, curl based installation may increase adoption.

Feature

Most helpful comment

Note that even users who have never used oh-my-zsh or any other similar tools could very well have an existing .zshrc. Deliberately refusing to make it easier for people to use your project is baffling to me. It seems like you're assuming that the only people who will have an existing .zshrc are oh-my-zsh users, and that if they can't immediately figure out what the problem is, they must be stupid boneheads.

In my experience, the easier you make it to install a project (I'm a big fan of automated scripts that do as much as possible for the user), and the better your documentation is, the less you have to respond to issues.

All 26 comments

Where is this idea at?

I just tried installing Prezto using the existing installation instructions;

setopt EXTENDED_GLOB
for rcfile in "${ZDOTDIR:-$HOME}"/.zprezto/runcoms/^README.md(.N); do
  ln -s "$rcfile" "${ZDOTDIR:-$HOME}/.${rcfile:t}"
done

But it didn't work because I already had ~/.zshrc installed, so of course zprezto/init.sh was never being run. This has taken me a good hour or so to figure out :(

My suggestion would be to have an installation script that prompted the user if .zshrc, or any other rc file already existed.

BTW, I love Prezto and it's way better than OMZ :D

If you write the script, I'll have a look.

At the very least it would be good to just change the README to describe how .zshrc needs to source init.sh

But an even better solution would be something along the lines of this pull request.

:)

I am the same person that suggested this pull request to provide an install script. The main reason I wrote it was to address the issue I mentioned a couple of comments above here. Namely that the installation instructions in the current README fail when there is an existing .zshrc

If you don't think an install.sh would be a suitable inclusion for the repo I would suggest that a small note be added to the README to remind the user to check that .zshrc has been succesfully linked or copied from prezto, otherwise the all-important zprezto/init.sh will never load.

But it didn't work because I already had ~/.zshrc installed, so of course zprezto/init.sh was never being run. This has taken me a good hour or so to figure out :(

Just wanted to put a +1 here. Same thing happened to me, after freshly installing zsh through homebrew – I'm assuming if it happened to me without having run any customization or anything previously, it's likely to be happening regularly. Even a note, or something, that covered this contingency: "if these files exist, you may need to copy the code in yourself" or something

+1 a one line install command would be awesome !

This happened to more than a couple of my students at @theironyard who followed the install instructions. The first time zsh is run on Mac OS X, it very helpfully attempts to lead you through an initial configuration, which has the side-effect of creating a .zshrc file. Adding a --force flag to the ln command in the Prezto install docs will clobber that initially empty .zshrc file, but that might not be the best approach for folks switching to Prezto from OMZ or hand-crafted configs. Better to look for existing files and move or offer to move them?

Somewhat unrelated, the install and usage instructions recommend editing .zpreztorc to add modules and set prompt theme, etc, but if Prezto is installed as a clone of _this_ repo and the files in runcoms are symlinked into ~, I can't very well commit my changes into my normal dotfiles repo, as one might expect. Happy to open a separate discussion on that point, of course, and submit PRs. The outcome of the two discussions seem intertwined, however, as the install script / instructions should reflect best practices for usage, maintenance, and upgrades.

The installation script ought to backup existing files into a hidden directory.

Prezto is designed to be forked, modified in place, and managed via Git.

+1 for this. I also had to use -f for the ln command in order for Prezto to work.

+1

It was _strongly_ disheartened after uninstalling OMZ at a whim and installing Prezto, only to see an extremely raw prompt:

devin%

FORTUNATELY I found this answer by googling "uninstally prezto" which led me to this issue. brew install prezto and brew uninstall prezto would be a stellar improvement - of course prezto would need to be accessible via linux package managers too

Prezto is not in Homebrew. Prezto is meant to be used via Git, not package managers.

Just to make it clear, the main issue people are having is _not_ that lack of an installation script (whether that is through a package manager or a curl one liner). It is the simple fact that the current installation instructions in the README fail, if you _already have_ an existing .zshrc. So in @devinrhode2's case, and anyone else coming from OMZ, then they will have a problem because .zshrc already exists.

The absolute most simple solution here is just a note in the README that .zshrc must not already exist. Or if it does, then the sourcing of zprezto/init.sh must be manually added.

@tombh :+1:

+1 on adding a quick note in the README that you must move or rename your existing .zshrc. I just ran into this as well.

For a longer term solution, would it not be possible for Prezto to append the sourcing lines to any existing .zshrc?

+1 to curl ... | sh

@devinrhode2 +1

I see that PRs have been submitted (and declined) since #240 (circa 2012). See the more refined effort in #395. Are you interested in PRs for this issue, @sorin-ionescu? Happy to continue refining #395 or take another stab at it, if so.

Of coarse.

I have neglected to add an installation script to discourage beginners from using Prezto to prevent the issues list blowing up with dumb questions and even dumber pull requests in an effort to not replicate the Wild Wild West nature of Oh-My-Zsh.

I can certainly understand that. The low-volume and volatility of Prezto it's one of my favorite features. ;)

Perhaps the proper management and grooming of a forked repository with submodules is sufficient to discourage adoption by absolute CLI noobs, but there's still a few non-trivial edge cases -- existing configuration files, for example -- that could be addressed to reduce the friction for intermediate-level developers.

Maybe some "declaration of intent" verbiage in the README would be welcomed, as well?

I don't want to discourage beginners from using Prezto. I want to discourage boneheads who will turn this issue list into Wild Wild West.

As has been explained by at least 7 people over 2.5 years, the main issue here is that the current README does not support people that have an existing .zshrc. Please, please, please can you try and understand this @sorin-ionescu

If anyone wants to support this, please comment on this PR: https://github.com/sorin-ionescu/prezto/pull/955#issuecomment-136671131

All we need to do is update the README, we don't need a one-line curl script to fix the main issue.

@tombh I understand. I just haven't cared because I've tried to keep Prezto away from people who don't know how to fix that issue. I have found it a useful barrier against people who would turn Prezto into the Wild Wild West Oh-My-Zsh is. They execute the instructions in the README. Prezto does not work. They go back to Oh-My-Zsh.

Just commenting to supporting this.

There is needless confusion that a couple of sentences in the README could have resolved.
I also wasted a couple of hours on what turned out to be a silly problem.

If your goal is to be better than oh-my-zsh, you're going to be getting a lot of oh-my-zsh users coming to try this out, just like myself. All these folks will have an existing .zshrc files because they just want to try out prezto before committing to it.

Note that even users who have never used oh-my-zsh or any other similar tools could very well have an existing .zshrc. Deliberately refusing to make it easier for people to use your project is baffling to me. It seems like you're assuming that the only people who will have an existing .zshrc are oh-my-zsh users, and that if they can't immediately figure out what the problem is, they must be stupid boneheads.

In my experience, the easier you make it to install a project (I'm a big fan of automated scripts that do as much as possible for the user), and the better your documentation is, the less you have to respond to issues.

@monfresh There is an issue for an installation script: #365.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mischaboldy picture mischaboldy  Â·  3Comments

michaelaye picture michaelaye  Â·  4Comments

askurihin picture askurihin  Â·  5Comments

hiqua picture hiqua  Â·  6Comments

belak picture belak  Â·  4Comments