Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Copy some ideas from a similar project called rad-shell #272

Open
brandon-fryslie opened this issue Jul 30, 2023 · 0 comments
Open

Comments

@brandon-fryslie
Copy link

brandon-fryslie commented Jul 30, 2023

Feature Request

This isn't really a feature request. I'm the creator of this project: https://github.com/brandon-fryslie/rad-shell. It's not widely popular but has maybe 30-40 users (mainly people I know).

It's an opinionated way for users to get started with zgen/zgenom. I'm going to use zgen in the rest of the doc because it's shorter to type, but just assume I mean zgenom.

One of the main reasons I wrote it was to remove oh-my-zsh in favor of prezto and keep my shell startup time as fast as possible (1s maximum). You can still load any oh-my-zsh plugins of course.

If this project supported a few of the ideas from rad-shell, it might be suitable for me to just drop that project and switch over. At the same time, it feels like there is a lot more complexity in this project so they might not be comparable.

Is your feature request related to a problem? Please describe.

There are a few problems with zsh-quickstart-kit. the first one is a blocker, the other 2 just annoyances.

  1. (blocker) The entire concept of keeping .zshrc symlinked to one in this repo is going to be a non-starter for a lot of people (me and everyone I know with an existing zsh setup). Most people aren't interested in learning complicated ways of creating these separate files to achieve basic functionality of editing their .zshrc file. This also breaks compatibility with various tools that write to .bashrc or .zshrc when they're installed. Personally I already have my .zshrc file symlinked into a repo containing all of my dotfiles, which makes this instantly incompatible unless I change my entire setup.

  2. (minor) The plugin loading mechanism is a bit complicated and unnecessarily exposes implementation details (requires zgen load in the plugin file).

  3. (nit) Installation of the project itself is more complicated than necessary.

Describe the solution you'd like

Note: I'm not actually requesting you copy any of this, but merely providing some food for thought. But if you do want to copy anything, it's all MIT license and you have full consent to copy any ideas or code that you like. Personally I like that rad-shell itself is very simple and lightweight. It seems to solve a few problems you've solved with this repo, but in a way that adds much less complexity and is more compatible with a normal zsh setup. It would be nice to have the best of both worlds.

Issue #1 (blocker) - .zshrc is symlinked into this repo and shouldn't be edited

The way issue #1 is solved in rad-shell is by having a separate file called rad-init.zsh that loads and configures zgen/zgenom and some other minimal defaults. The rad-shell repo itself is installed as a zgen plugin so it is also updated automatically with the rest of the plugins. It's symlinked into ~/.rad-shell and you can enable the entire setup simply by putting source $HOME/.rad-shell/rad-init.zsh at the top of your ~/.zshrc (any config options for rad-shell or zgen would go before this, but it's typically not necessary). The default .zshrc looks like this:

# Initialize rad-shell and plugins
source $HOME/.rad-shell/rad-init.zsh

and you're free to do whatever you want with the rest of the file without needing to keep it locked to a repo (or god forbid fork the repo just to update this single file). This is a far better solution than symlinking .zshrc to your repo for several reasons:

  • New users don't need to learn a bunch of custom directories and file loading orders just to use this project
  • Compatible with everything that writes to .zshrc
  • Achieves the same benefits of keeping the configuration of zgen behind the scenes
  • Keeps your .zshrc file clean

My .zshrc file is already symlinked into a repo I keep for my dotfiles. It would be cool to try this out but it's basically a non-starter without spending hours reconfiguring everything and committing entirely to doing it this way.

Issue #2 (minor) - Plugin loading is unnecessarily complicated

I'm sure there are plenty of reasons for the plugin loading complexity, but rad-shell uses a single file called .rad-plugins. Here's the default:

# Load Homebrew near the top
brandon-fryslie/rad-plugins homebrew

# Load some dotfile aliases
brandon-fryslie/rad-plugins dotfiles

# 3rd Party plugins
ohmyzsh/ohmyzsh plugins/docker

# Enhanced fork of zaw
brandon-fryslie/zaw
zsh-users/zsh-autosuggestions / develop
zsh-users/zsh-completions

brandon-fryslie/rad-plugins zaw
brandon-fryslie/rad-plugins docker
brandon-fryslie/rad-plugins git
brandon-fryslie/rad-plugins shell-tools
brandon-fryslie/rad-plugins rad-dev

### Themes
### Add themes here.  We use git-taculous by default.  You can also use most oh-my-zsh themes or a custom theme
### Remove or comment out the default theme if you want to use a different them
brandon-fryslie/rad-plugins git-taculous-theme/git-taculous

# oh-my-zsh theme example (https://github.com/ohmyzsh/ohmyzsh/wiki/Themes)
# ohmyzsh/ohmyzsh themes/amuse
### / Themes

# Load these last
brandon-fryslie/zsh-syntax-highlighting
brandon-fryslie/rad-plugins shell-customize

These lines are simply passed to zgen load (zgenom load). zgen is configured to rebuild the cache when this file changes. Nothing crazy, but makes it a bit more simple and intuitive.

The most basic prezto plugins are added internally and it's just enough to provide the functionality for standard themes and plugins. Likely I'll make this configurable at some point or simplify it by moving it to the rad-plugins file.

It's a bit of a turnoff to learn all of the intricate loading details of the plugins files in this project. Like I said, I'm sure they each were added for a reason, but it's convenient to have something simple that doesn't require looking up documentation each time to figure out what needs to go where. I also like that I'm decoupled from zgen or zgenom or zgemonaiac or whatever it will be called when zgenom becomes unmaintained. It's an implementation detail users don't need to think about.

Issue #3 (nit) - Installation is complicated

Why do I need to run a bunch of commands to set this project up? this is how you set up rad-shell:

# With default plugins
curl -o- https://raw.githubusercontent.com/brandon-fryslie/rad-shell/master/install.sh | bash

# Without default plugins
export SKIP_DEFAULT_PLUGINS=true; curl -o- https://raw.githubusercontent.com/brandon-fryslie/rad-shell/master/install.sh | bash

I'm also thinking of adding an option to set this all up in a temporary directory somewhere so users can play around with it without needing to adjust any of their original configuration. A lot of people I've talked to would like to try projects like this out without impacting their existing setup. Without an automated installation script, that would be very tedious and require intimate knowledge of how zsh and zgen/zgenom are configured. With an installation script it's very doable.

Maybe some people are wary of running an install script from some random repo, but this is a zsh plugin manager and its entire purpose is to run arbitrary code from random repos. Having an install script makes it much easier for users and allows you to automatically configure some common options if you want. If I could run a single line script to install this, disable your default plugins, disable oh-my-zsh, and enable prezto, that would remove a lot of friction.

Describe alternatives you've considered

I use rad-shell and it's great. But if this supported a few of the basic things I like about rad-shell I could use this instead and get all of the additional functionality included in this project. Most of the rad-shell functionality I actually care about is in the plugins themselves which can be loaded by any zsh plugin manager: https://github.com/brandon-fryslie/rad-plugins

The primary blocker is the required symlinking of .zshrc. Fixing that would remove so much complexity.

Additional context

Your project is awesome and I hope you didn't take offense in any way. It's clear you put a ton of time and effort into this. I was just being frank and hopefully providing some ideas that in my opinion would improve the project. I would love to try it out but that isn't easy right now, with all the extra symlinks, folders, files, config options, etc needed just to get an equivalent setup to what I already have.

Main root problems:

  • Not easy to install (rad-shell is one line install script)
  • Not easy to uninstall (to stop using rad-shell, you need to restore the backup of your ./zshrc. That's it. to fully uninstall, you need to remove 1 folder, a symlink, and 2 files)
  • Not compatible with anyone's standard zsh workflow, which includes being able to modify your own ~/.zshrc file

Minor problems:

  • Loading plugins from a file requires including the name of the command to load them (e.g., zgen load abc/xyz). This is an implementation detail that isn't really necessary and should be omitted IMO. By keeping that out of the plugins file, I can change that at any time without requiring users to make modifications to their configuration (e.g., switch zgen to zgenom and automatically get the expanded functionality of zgenom and not rely on the zgen compatibility layer).

Thanks again and I hope your project continues to be very successful. It's very cool. If I can contribute to reducing some of the complexity I'd be delighted, but I know changing things is difficult and completely understand if my opinions do not line up with your opinions.

I mainly just wanted to share that these problems are all solved relatively elegantly in rad-shell and could probably be trivially implemented in this project. It would vastly improve the user experience and ability for users with existing non-trivial zsh setups use your project. There would need to be some migration code somewhere, but hopefully it wouldn't be that difficult.

Happy to answer any follow up questions but the code in the rad-shell repo is pretty self explanatory. Installation is ~100 lines total and that includes the content of the default files and some helper functions. The actual code you'd need to replicate an equivalent setup is probably 20 lines or less (except migration of your existing users).

These 2 files include everything you would need to look at:

  • https://github.com/brandon-fryslie/rad-shell/blob/master/install.sh
    • Install script
  • https://github.com/brandon-fryslie/rad-shell/blob/master/rad-init.zsh
    • Initializes zgen/zgenom so we don't need to keep that junk in the .zshrc file itself
    • Requires just a single line in the .zshrc source $HOME/.rad-shell/rad-init.zsh. you can update things under the hood to your hearts content since this file itself is part of a zgen plugin and will update with everything else
    • This would allow users to modify .zshrc without any issues, which I guarantee is a blocker for at least some percentage of people who would otherwise use your project
    • This file also loads plugins from .rad-plugins. as you can see is the code is trivial but it abstracts away the implementation details without losing any functionality over calling zgen load directly. overall it's a pretty minor thing though

If you read this far, thanks so much for your time. Take care.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant