prezto-inactive-community-fork / prezto

THIS FORK HAS SHUT DOWN – use the original!
https://github.com/sorin-ionescu/prezto
MIT License
116 stars 18 forks source link

lazy loading node with homebrew installed nvm issues. #24

Open ahmedelgabri opened 7 years ago

ahmedelgabri commented 7 years ago

It doesn't work properly, doesn't load node from nvm & doesn't load globally installed modules too. Some issues I found:

if [[ -s "$HOME/.nvm/nvm.sh" ]]; then # 1
  lazy_load_nvm "$HOME/.nvm"

# Load package manager installed NVM into the shell session.
elif (( $+commands[brew] )) && [[ -d "$(brew --prefix nvm 2>/dev/null)" ]]; then
  lazy_load_nvm "$(brew --prefix nvm)" #2

# Return if requirements are not found.
elif (( ! $+commands[node] )); then
  return 1
fi
NODE_GLOBALS=(`find $NVM_DIR/versions/node -maxdepth 3 \( -type l -o -type f \) -wholename '*/bin/*' | xargs -n1 basename | sort | uniq`) #3
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" #4
  1. nvm.sh is not inside ~/.nvm it's inside $(brew --prefix nvm)
  2. When lazy_load_nvm gets passed $(brew --prefix nvm) as $1
  3. $NODE_GLOBALS doesn't work because the versions are inside ~/.nvm/versions not inside $(brew --prefix nvm)/versions
  4. Which loads the nvm but without $NODE_GLOBALS

Maybe this was an old behaviour that's why this script was created like this, I dunno.

For example this works for me

lazy_load_nvm() {
  NVM_DIR=$1
+ VERSIONS_DIR=$2
  # Skip adding binaries if there is no node version installed yet
  if [ -d $2/versions/node ]; then
+   NODE_GLOBALS=(`find $VERSIONS_DIR/versions/node -maxdepth 3 \( -type l -o -type f \) -wholename '*/bin/*' | xargs -n1 basename | sort | uniq`)
  fi
  NODE_GLOBALS+=("nvm")

  load_nvm () {
    # Unset placeholder functions
    for cmd in "${NODE_GLOBALS[@]}"; do unset -f ${cmd} &>/dev/null; done

    # Load NVM
+   [ -s "$(brew --prefix nvm)/nvm.sh" ] && source "$(brew --prefix nvm)/nvm.sh"
-  # [ -s "$NVM_DIR/nvm.sh" ] && source "$NVM_DIR/nvm.sh" # No clue why this doesn't work although they are identical

    # (Optional) Set the version of node to use from ~/.nvmrc if available
    nvm use 2> /dev/null 1>&2 || true

    # Do not reload nvm again
    export NVM_LOADED=1
  }

  for cmd in "${NODE_GLOBALS[@]}"; do
    # Skip defining the function if the binary is already in the PATH
    if ! which ${cmd} &>/dev/null; then
      eval "${cmd}() { unset -f ${cmd} &>/dev/null; [ -z \${NVM_LOADED+x} ] && load_nvm; ${cmd} \$@; }"
    fi
  done
}

...

+  lazy_load_nvm "$(brew --prefix nvm)" "$HOME/.nvm"

I'm by no means a shell expert though :)

sodiumjoe commented 7 years ago

maybe prezto should incorporate https://github.com/lukechilds/zsh-nvm, which has a lazy-load mode that seems to work at least as well as prezto's built-in version

paulmelnikow commented 7 years ago

Thanks for this issue.

Would either you like to work up a pull request?

@lukechilds, would you be interested in replacing what we've got with your module?

I'm having trouble with nvm lazy-loading on Mac OS and would be happy to review and test.

Added: The problem I'm having is #15.

ahmedelgabri commented 7 years ago

@paulmelnikow I think you can use zsh-nvm with prezto normally if it's not a module not 100% sure but it should work check the manual install https://github.com/lukechilds/zsh-nvm#manually

I don't use prezto anymore, I switched to zim with zplug & installed zsh-nvm too & that fixed all my issues.

paulmelnikow commented 7 years ago

Ah cool, maybe someone can give that a shot. Would be great to have it integrated as an external module, especially given our nvm support is buggy.

I've been following Zim, which started off as an endeavor to maintain a Prezto fork, before Matt, the author decided to rewrite it instead. It looks really promising. Technically in great shape, and also takes a smart approach of a small core. I'm curious if Matt would be interested in transitioning it to a community-managed project. There are some big advantages in what you can do when you empower and engage a community.

I've also been playing around with the plugin managers. There are a lot of them! There's zplug, Antigen, and two projects (1, 2) called zpm. Why did you decide on zplug?

ahmedelgabri commented 7 years ago

zim now has it's own organization BTW.

Regarding zplug, honestly, it just looked simple, fast & familiar. Since it's similar to vim-plugwhich I use to manage my vim plugins — they even mention that it was inspired by it

paulmelnikow commented 7 years ago

Re zim, that's good to know! I hadn't seen the new organization yet. I'll have to catch up on those discussions.

Interesting, a bunch of the zsh plugin managers seem to be inspired by vim plugin managers. Seems like the vim community is ahead of the game.

sodiumjoe commented 7 years ago

I just recently tried to switch off of prezto to a zsh plugin manager, but they all had slower zsh startup times for my setup than prezto. I'll have to try zim.

lukechilds commented 7 years ago

@paulmelnikow Sorry, I'm pretty busy with other projects at the moment.

I'd probably recommend using a plugin manager and just using zsh-nvm. It gets updated fairly frequently.

If you really want to embed it in prezto it shouldn't be a big job. You should just be able to just copy/paste the lazy load function.

lukechilds commented 7 years ago

@sodiumjoe Yeah the tradeoff for the extra modularity is increased complexity in the loaders and therefore slower startup. However most modern plugin managers have some sort of caching functionality to make the difference pretty small.

sodiumjoe commented 7 years ago

@lukechilds yeah that makes sense, though I each with all available caching and prezto was still faster. For my own personal use, I don't mess with my zsh setup that often, while I open new shells all the time, so the tradeoff doesn't really make sense. This makes me hopeful about zim, though!