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

Proposal to Simplify OH-MY-ZSH #377

Closed
sorin-ionescu opened this issue May 30, 2011 · 87 comments
Closed

Proposal to Simplify OH-MY-ZSH #377

sorin-ionescu opened this issue May 30, 2011 · 87 comments
Assignees
Labels
Milestone

Comments

@sorin-ionescu
Copy link
Contributor

@sorin-ionescu sorin-ionescu commented May 30, 2011

Organising code inside of OH-MY-ZSH is becoming unnecessarily complex. For a while, there has been the /custom directory to dump files that override or append to the functionality of /lib, /plugins, and /themes.

Then the ability to override /plugins via /custom/plugins was added (#89). Now, a new proposal has been submitted to allow the overriding of /themes (#376) and /lib (in the comments to #376) via /custom/themes and /custom/lib respectively.

Additionally, there is the /functions directory (b865f2a) for dumping miscellaneous functions and the /completions directory (#351) for dumping miscellaneous completions.

These directories are unnecessary for we already have a software configuration management (SCM) tool called Git. We should use Git exclusively.

I propose that we get rid of /custom, and edit /lib, /plugins, and /themes directly. We also get rid of /functions, and /completions to encourage the creation of plugins instead of dumping random code in those directories.

Pulling updates while retaining customisations is easy by recursively merging conflicting hunks by favouring our version.

git pull --no-commit --strategy=recursive -X ours robbyrussell master

Updates should always be checked for dangerous code (rm -rf /). Hence we use pull --no-commit to stop Git from auto-committing to let us check the files even when there is a clean merge.

git status
*** Check the files listed. ***
git commit

Lastly, if we use Git exclusively, the /tools directory becomes unnecessary and should be removed.

Keep It Simple!

@vguerci
Copy link
Contributor

@vguerci vguerci commented May 31, 2011

I mostly agree with this, KISS ftw.

The only opposable argument I see to this is that using git is less "user-friendly" than dropping a file to "custom".
But this is a reasonable assumption that people wanting to "override" plugins has the git skills required...

About the /tools I'm not sure about, the installer could be moved to a gist, the uninstaller is not that important, but I like the auto-upgrade feature... Hmm could it be extracted as plug-in? (Fyi, I use a local branch with a modified autoupdate, which shows diff stats and then rebase, every day)

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented May 31, 2011

The SHELL is not user friendly. We do what we can to mitigate 40 years of baggage. Responsible users keep their dotfiles under version control. In my case OMZ is a submodule which points to my fork. So, whether a file with new functions is dropped into /custom or new functions are appended to /lib/functions.zsh, either operation must be committed. What is not easy is not learning version control and having the changes go 'POOF!' There is no fun in writing déjà vu code.

Yes, the installer can be moved into a Gist, and auto-upgrade can be moved into a plugin. In any case, auto-upgrade only reliably works if the core is never modified for no chance of merge conflicts to arise, and the core has not changed significantly to break code in /custom, /functions, and /completions.

I have never used the upgrade script. Since I write plugins and fix OMZ, I have rarely have had a non-eventful manual upgrade.

You cannot use rebase if you want to share your OMZ fork. You have to merge.

I am almost done creating a simplified OMZ for my own use.

KISS FTW!

@robbyrussell
Copy link
Collaborator

@robbyrussell robbyrussell commented Jun 1, 2011

I'm of the opinion that there are different user groups of ohmyzsh. There are people who wouldn't lose any sleep if their zsh config disappeared... and they had to start over and there are those who are much more invested into their custom configuration. I'm not sure who ohmyzsh is entirely best fit for. In many ways, I see it as a huge stepping stone from a stock zsh configuration to something easy to get going more than I see it as a tool for advanced users.

Having said that... could ohmyzsh be organized in a way to help lead people through the novice to "expert" phases? Definitely... where do I want OMZ to focus it's attention? On the early adopter/novice phase. I want to keep that initial process as easy/simple for someone to get going. As people want to customize/optimize... I think there is a lot we can do to facilitate that journey, but want to make sure this project honors our novices as first class citizens.

The experts don't need this project as much. Once we start getting into more complicated git configurations... we could start to overwhelm novices (and myself for that matter). I'm hardly a git expert and would want to see OMZ provide useful scripts to handle a lot of the proposed features. Perhaps we can chat further once I see how you've setup things in your simplified version and we can share some thoughts together.

Sincerely,
A former novice

@gutenye
Copy link

@gutenye gutenye commented Jun 6, 2011

I love the idea. where can I give a try and report issues?

@meh
Copy link
Contributor

@meh meh commented Jun 6, 2011

+1 on this, just make some wrapping scripts for noobs and everyone's happy.

@giddie
Copy link
Contributor

@giddie giddie commented Sep 19, 2011

I like this very much; I already maintain a personal fork with modified libs & plugins for use on several machines. I do use the custom directory, but it's for aliases or tweaks that are specific to that account / machine. I wouldn't really want to lose that, but I see no need for a custom plugins or function directory, as I modify the standard ones in my fork.

@Dieterbe
Copy link
Contributor

@Dieterbe Dieterbe commented Jan 10, 2012

see also #79 where I introduced a git approach

@jedahan
Copy link

@jedahan jedahan commented Jan 26, 2012

Sorin's fork works very well so far, @robbyrussell what set of feature coverage would you ideally want before reconsidering his approach? Even better if you could list the most important first. I have already implemented a rough upgrade plugin that works similarly to the current upgrade_oh_my_zsh() and submitted to zsh-syntax-highlighting support for the fork's method of plugin loading.

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jan 26, 2012

I intended to write an extensive post documenting all the changes. I wanted to commit a few more changes before announcing that I have pushed my fork to GitHub for public scrutiny, but @jedahan found it first.

@vguerci
Copy link
Contributor

@vguerci vguerci commented Jan 26, 2012

Only that! Good job :)

@Dieterbe
Copy link
Contributor

@Dieterbe Dieterbe commented Jan 26, 2012

looking forward to the extensive post though. :)

@jedahan
Copy link

@jedahan jedahan commented Jan 26, 2012

Ahh sorry for busting the door open before the table was set @sorin-ionescu !

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jan 26, 2012

My OMZ fork has been seven months in the making. I have started it because OMZ has a very bad reputation with the Zsh developers because users join #zsh on FreeNode to whine that something is broken.

Shell scripting is hard; it has 40 years of baggage. Not to mention, most of the code on the Internet is full of bashisms. While said bashisms may be supported, Zsh is closer to KSH than BASH, and it often has a more efficient way of completing tasks than BASH.

A large portion of OMZ has been copied/pasted and assumed to work. While a pull request may work or half-work for a submitter, it may not work for everybody. A green 'this pull request can be automatically merged' bar is not enough to accept a pull request.

@robbyrussell has asked for help in the past. This is it.

While I do not have a scientific metric, probably 90-95% of the core (what used to be /lib) I have thrown away and rewritten. Plugins have also been cleaned up, have had portions rewritten, or in some cases removed.

I encourage you to go through all files and compare my fork with the original as well as reading the Git log.

$EDITOR **/*~(completions)/*(.)
@Dieterbe
Copy link
Contributor

@Dieterbe Dieterbe commented Jan 30, 2012

Pulling updates while retaining customisations is easy by recursively merging conflicting hunks by favouring our version.

not sure if that's a good idea. I think for each merge conflict, you should just look at your own changes and the upstream changes and figure out which make most sense. Sometimes you want to keep your own changes, sometimes you want the upstream version, sometimes a bit of both. It's impossible to say in advance.

  1. merge conflicts are not a "bad thing which must be avoided at all costs". see my detailed explanation @ #79 (comment)

  2. OMZ has AFAIK never had a policy which explains how things should go, maybe we should make a list of rules for our version, such as:

  • leverage git, don't use 'custom' directories and the likes, encourage git branches and "the right way"
  • prefer (highly commented) zsh code over bashims and posix-isms where they make sense.
  • prefer opt-in features over opt-out. especially for things which may not be beneficial for everyone.
    (examples: i strongly dislike some default things like bindkey -s '\e.' "..\n" and the time output for commands which take a bit longer, I also don't like how plugins pollute my alias namespace with aliases I'll never use)
@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jan 30, 2012

Pulling updates while retaining customisations by recursively merging conflicting hunks by favouring our version is the only way for auto-update to work if such functionality is to be added. Personally, I do not like auto-update, but I do have a branch where I am toying with an implementation.

Agree:

  • I have cleaned up and organised OMZ by using a non-written list of rules.
  • I leverage Git over a directory hierarchy.
  • I prefer Zsh code over bashims. I have added comments where appropriate, but I do not have a high comment density.

Disagree:

  • An opt-in system would make configuration and implementation overly complicated. OMZ should provide sane defaults. If you do not like a particular set of key bindings nor aliases, edit or delete them. I do not think that I have that particular key binding nor have I defined a particular time format. Have you actually read the code or used my fork?
@Dieterbe
Copy link
Contributor

@Dieterbe Dieterbe commented Jan 30, 2012

  • high comment density is my suggestion not because of ideological goals, but merely because I assume most people trying to hack on [your fork of] OMZ aren't that experienced zsh scripters. high comment density may get in the way of experienced contributors, but the gates it opens for other people to more easily get involved should be worth it.
  • if with autoupdating you mean "starting the update process automatically" and "deal with all conflicts automatically", that just cannot work, period. Both with the standard OMZ methods (different files in custom dirs), as well as with the improved git method, if a user changes a certain behavior/functionality, and upstream changes that same bit as well, it's just impossible to automatically know which version should be preferred. The user is the only person who can know and manual intervention is needed. manual intervention should happen, it's the only right way and it makes no sense to try to avoid it.
  • I started using your fork now, the examples i gave are with robby's version.
  • I agree there should be sane defaults. Let's just try it your way and if I encounter anything I consider insane, I'll shout.
@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jan 30, 2012

Feel free to add comments where needed and open a pull request. Be forewarned that I am a grammar Nazi. :)

@aleksey-orekhov
Copy link

@aleksey-orekhov aleksey-orekhov commented Feb 15, 2012

@sorin-ionescu

I notice that your fork of OMZ doesn't have all of the plugins currently available for OMZ. What would be the best way of including some of my favorites, like extract (ironically enough, something that you wrote), using your fork?

Would it be as simple as copying over the plugin and renaming the file to be loaded to 'init.zsh'?

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Feb 15, 2012

@Cruser Rename old plugins to init.zsh. The names of the plugins are deceiving. Some plugins have been renamed while others have been merged. A few were indeed deleted. extract is there under archive.

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Feb 21, 2012

@robbyrussell @eddorre Have you had a look at this?

@aleksey-orekhov
Copy link

@aleksey-orekhov aleksey-orekhov commented Feb 21, 2012

I've switched to sorin-ionescu's version on two machines and so far so good. It definitely feels a bit more responsive.

my two cents.

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jun 10, 2012

@jgosmann I also track OMZ in my dot-files repository, and I track my dot-files repository in my tilde repository. It works fine.

@jgosmann
Copy link

@jgosmann jgosmann commented Jun 10, 2012

The problem isn't tracking OMZ in the dot-files repository and that's also what I do (dotzshrc). But I want to be able to track my own theme without forking OMZ. Doing that just to add this file seems to make it unnecessarily complicated to synchronize changes to to theme:

Process right know
  1. Change the theme on one computer and commit.
  2. Push changes.
  3. Pull changes on all other computers.
Process with forked OMZ

(as I imagine it, I haven't actually tried it; maybe there is an easier solution I do not know?)

  1. Change the theme on one computer and commit
  2. Push changes to forked OMZ repository.
  3. Commit the change of the version of the submodule in the dot-files repository
  4. Push those changes
  5. Pull those changes on all other computers
  6. git submodule update
@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jun 10, 2012

You have to do the following once.

  1. Fork my OMZ
  2. Replace my OMZ with your OMZ in your dot files.

Then do the following.

  1. Do your changes inside your dot files OMZ.
  2. Commit.
  3. Push
  4. Pull your changes on all computers
@jgosmann
Copy link

@jgosmann jgosmann commented Jun 10, 2012

Played a bit around and the result so far: If I only commit the changes to the OMZ submodule, the parent (local) dot-files repository will show uncommitted changes as long as I do not commit to that repository, too. Moreover, if I clone the (remote) dot-files repository in that stage it will not checkout the most current version of the OMZ submodule. I have to do another pull in the OMZ submodule and I have even to specify the branch as the working copy will be on no branch.

Sure it works somehow. But to me it feels not so clean and simple.

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jun 10, 2012

There is a giant aliases file in the Git module. Just type gSU at the top of the hierarchy to update all submodules.

If you do not like the fact that you have to commit in the parent repository, you can use git subtrees. There is a git-subtree script in the contrib folder of Git that makes things very easy.

Yes, it's a little bit of an initial pain until you get the hang of it, but it's better. Creating convoluted directory hierarchies to not modify third-party dot files directly creates nothing but problems in the long run.

@jgosmann
Copy link

@jgosmann jgosmann commented Jun 10, 2012

I didn't know about subtrees, they might be an option. Probably I have to think about all of this a bit more ...

@robbyrussell
Copy link
Collaborator

@robbyrussell robbyrussell commented Jun 13, 2012

@sorin-ionescu

You lost me at "you can use git subtrees." (speaking on behalf of a lot of OMZ users who don't know how git works that much...)

@ColinHebert : RE: "Recently his fork had a major change which implied a mandatory modification of the .zshrc file, and auto update wouldn't have taken care of that and could possibly have make ZSH unusable"

Hmm, I don't believe that has been an issue with my version of OMZ... because we've always ensured that new updates don't BREAK existing config files. (i vaguely recall a small issue we had once, but we caught it within a few hours and fixed it before most people would have had an auto-update run)

I'm still open for exploring a 2.0, but it sounds like @sorin-ionescu and I have a difference of opinion on who the target audience is. From my perspective, what has been proposed looks too complex for people who aren't that comfortable with a shell already. (please refer back to this comment for my reasons).

From what I can tell... OMZ has an increasingly growing fan base and the biggest problem we have is that I, personally, can't keep up with all the pull-requests, which I'm addressing by tapping a few shoulders to aid me... but having gone back and forth over default conventions and philosophies, I'm going to stick to my guns on this one. I think @sorin-ionescu presents a great option for people who want to get a bit more clever, but I think my approach is best suited for the folks that I've been catering to all this time.

My approach is...

  • people run a shell command, it switches you over
  • they edit a config file
  • they select a theme (seem to be the most popular thing people want... personalization)
  • maybe look into plugins (maybe... doubt most are)

all of this without needing to know much/if anything about git.

Anyhow.. back to looking at pull requests.

@robbyrussell
Copy link
Collaborator

@robbyrussell robbyrussell commented Jun 13, 2012

Am going to close this issue for now as I don't believe OMZ suffers from being the opposite of simple (to use) at the moment. If we want to discus performance concerns, let's do those on a case-by-case basis.

Perhaps I'm not the average OMZ user... maybe I'm completely wrong, but I don't get the sense that many people know how to use some of the more advanced features... which might indicate a lack of learning resources/knowledge base. Until I'm convinced otherwise, I'm going to go about organizing and managing things in a similar manner and will always favor small/incremental updates to the project/framework over proposals to re-engineer the entire thing. (but am glad that open source makes it so easy for some people to do so!)

Onwards we march!

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jun 13, 2012

There is a communication issue here.

Git

@robbyrussell, you are confused. @jgosmann has added OMZ as a submodule in his dot files. Whether he customises OMZ or just updates it via whatever mechanism, he has to commit in the parent project. That's how Git submodules work. I gave him the option to use subtrees if he does not like that. My OMZ fork does not require the use of subtrees. I also do not use subtrees.

Your fork is dependent on Git. It is dependent on Git to install, and it is depended on Git to update. If there is no Git, it cannot be installed with the script, and if there is a merge problem during the update, it leaves the user holding the problem.

Breaking

I have always considered my fork as a work in progress until all the README files are done (there a few more to go). This was not a secret. I have communicated this. I am not sure to which breaking change you are referring, the merging of the alias and utility modules is not a breaking change. It does give a warning about the alias module not being found, which informs the user to remove it from zshrc. That issue has been up there for two months.

There was a partial breaking change some weeks ago, which was absolutely necessary because using the five rc files is what Zsh expects, and it's the only way for it to work properly. The change went well. I believe that there was only one issue opened claiming that something didn't work.

Almost all bugs have been fixed in a few hours.

Your OMZ used to break all the time when I used to use it because whatever I have had in custom used to go out of sync with /lib and /plugins. It may have changed in the last year, but based on the amount of issues opened, I would argue that is not the case. Config files are easy to fix. Code buried inside OMZ is not.

Why do you have so many pull requests? Because it's broken, and many people are trying to fix the same thing. There are many duplicate pull requests. Also, there are a lot of me too pull requests that benefit no other person.

That said, the configuration files in my fork have stabilised.

Auto-update can migrate the zshrc using regular expressions and search and replace.

Philosophy Between Our Forks

  • Users run a shell command, which switches them over (there is no install script yet).
  • Users edit a config file (same).
  • Users select a theme (same)
  • Users look into plugins/modules (same).

If users don't customise, as you claim, they don't need to know Git to use my fork either. Nevertheless, the amount of forks begs to differ, and since GitHub gives no other metric than the number of watchers and forks, it's the only metric we can use.

My fork has been a year in the making. It didn't drop over night. I have used incremental updates myself whenever I had time.

Have you ever used my fork for at least a week?

Sideways we march! :)

@skwp
Copy link

@skwp skwp commented Jun 14, 2012

I want to speak up that I am the maintainer of a 700+ watcher dotfiles project and I have recommended omz-sorin to my users since a few months back. To be honest, I am not an expert ZSH user and my first motivation for upgrading to sorin's branch was the fact that he had not included the somewhat annoying (my opinion) weekly update feature :).

It also struck me that sorin really knew what he was doing with regard to zsh, and was producing a very zsh-specific project. As I learned more about the differences, I could see that sorin's version is likely to be more maintainable by people who really know zsh.

From a usability standpoint, I see a lot less "stuff" in sorin's fork, and so I believe it's easier to comprehend. Rather than plugins/libs/modules/templates, there are really only modules, and they're well organized as directories. Being relatively new to ZSH, it's easy for me to understand the organization of this codebase.

I don't know what else to add other than I understand that sorin's branch has grown very slowly over time to become a very clean and modularized set of plugins, yet it has greatly diverged from robby's. I can understand that robby would have a hard time merging something that was drastically different from what he has come to maintain. At the end of the day, that would mean that robby would be responsible for dealing with the change requests, and clearly there's already a crazy overrun of pull requests on this project.

My proposal is @sorin-ionescu , don't worry so much about this project, and go ahead and develop your fork without worrying about trying to merge back with robby's version. You have a dedicated support base, and we don't need everyone to switch over to it. In fact, it may cause the same pull request chaos that robby has to deal with. I'd rather keep the omz-sorin secret all to myself :) I will continue promoting it to my users. Thanks @sorin-ionescu for an awesome implementation and thanks @robbyrussell for the original inspiration. Both of you have done tremendous work for getting lazy bash users like myself to see the enlightenment of zsh.

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jun 14, 2012

@skwp, the motivation for my fork was to help the users of Oh My Zsh, not to take over @robbyrussell's project. That said, I will not keep it as a shadow of its parent. If it's not going to be merged into the parent project, I would have to ask @github to separate the two projects, and I would have to rename and rebrand it. I have not thought of clever name besides zsh.d akin to other dot d directories in /etc.

@skwp
Copy link

@skwp skwp commented Jun 14, 2012

I would agree with this. I almost did my dotfiles project as a fork of Janus but I was not happy with how they organized things, so I took my own path. I don't think there's anything wrong with that, and probably less load on Robby to try to merge these things. I like that you're trying to do a good thing, and I think users in the end care less than you or Robby do about the way your projects are handled. People will be happy either way :)

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Jun 15, 2012

Fans, contribute to the renaming and rebranding of the project.

@febs
Copy link

@febs febs commented Oct 11, 2012

I got a 404 following that link.

@ColinHebert
Copy link

@ColinHebert ColinHebert commented Oct 11, 2012

The project has been since renamed into prezto

@gsemet
Copy link
Contributor

@gsemet gsemet commented Feb 14, 2013

Hello. I don't know if the omz project is dead but I've started hacking on it since it has a very clean base for the evolution (mainly new plugin) I need. Does this project still maintained?

@skwp
Copy link

@skwp skwp commented Feb 14, 2013

Prezto => https://github.com/sorin-ionescu/prezto is actively maintained

@hotpxl
Copy link

@hotpxl hotpxl commented Nov 26, 2013

This debate is awesome..

@sorin-ionescu
Copy link
Contributor Author

@sorin-ionescu sorin-ionescu commented Nov 26, 2013

@kevinleeone It's called Prezto — Instantly Awesome Zsh.

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

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.