Proposal to Simplify OH-MY-ZSH #377
Comments
|
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". 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) |
|
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! |
|
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, |
|
I love the idea. where can I give a try and report issues? |
|
+1 on this, just make some wrapping scripts for noobs and everyone's happy. |
|
I like this very much; I already maintain a personal fork with modified libs & plugins for use on several machines. I do use the |
|
see also #79 where I introduced a git approach |
|
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. |
|
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. |
|
Only that! Good job :) |
|
looking forward to the extensive post though. :) |
|
Ahh sorry for busting the door open before the table was set @sorin-ionescu ! |
|
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. |
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.
|
|
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:
Disagree:
|
|
|
Feel free to add comments where needed and open a pull request. Be forewarned that I am a grammar Nazi. :) |
|
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'? |
|
@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. |
|
@robbyrussell @eddorre Have you had a look at this? |
|
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. |
|
Finally, someone else agrees with me, forking the repository just to Wael Nasreddine On Jun 10, 2012, at 11:46, Jan Gosmann
|
|
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
Process with forked OMZ(as I imagine it, I haven't actually tried it; maybe there is an easier solution I do not know?)
|
|
You have to do the following once.
Then do the following.
|
|
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. |
|
There is a giant aliases file in the Git module. Just type If you do not like the fact that you have to commit in the parent repository, you can use git subtrees. There is a 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. |
|
I didn't know about subtrees, they might be an option. Probably I have to think about all of this a bit more ... |
|
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...
all of this without needing to know much/if anything about git. Anyhow.. back to looking at pull requests. |
|
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! |
|
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. BreakingI 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
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! :) |
|
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. |
|
@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 |
|
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 :) |
|
Fans, contribute to the renaming and rebranding of the project. |
|
I got a 404 following that link. |
|
The project has been since renamed into prezto |
|
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? |
|
Prezto => https://github.com/sorin-ionescu/prezto is actively maintained |
|
This debate is awesome.. |
|
@kevinleeone It's called Prezto — Instantly Awesome Zsh. |
ghost
mentioned this issue
and others
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.
Updates should always be checked for dangerous code (
rm -rf /). Hence we usepull --no-committo stop Git from auto-committing to let us check the files even when there is a clean merge.Lastly, if we use Git exclusively, the /tools directory becomes unnecessary and should be removed.
Keep It Simple!
The text was updated successfully, but these errors were encountered: