Plans for a separate prezto-contrib repository #1483
Comments
belak
assigned sorin-ionescu, indrajitr, belak, johnpneumann, jeffwidman and facastagnini
|
For whatever reason it won't let me assign @paulmelnikow as well. |
|
I'm not a maintainer on this project, though if I can help with the transition let me know! |
|
Oh, my mistake. I seem to remember you being helpful with the fork. If you want contributor access the contrib repo when it's created, that definitely seems like a possibility given your help in the past. I can't think of anything right now, but I'll ping you again if we could use your help. :) On a semi-related note, any chance you could take a look at prezto-inactive-community-fork#64? It looks like I don't have push access to that repo and we've gotten a few issues filed here lately with people using that repo. |
|
Sounds good! Sure, sorry for the delay! |
|
So this looks good to me. I don’t know that I love the idea of having the ability to update contrib, BUT I think that by not having that functionality it may deter folks from using it (because we’re officially supporting it as an optional place to pull from).
However it could get messy if folks are pulling in repos from other sources and they’re all not from contrib, so there’s a fine line of flexibility versus convenience. I’d prefer flexibility over convenience, but that’s a personal thing.
In re: the blocking PR I thought I left some notes on it earlier this week (in regards to thoroughly testing and vetting it), but I’ll check again and do so if I haven’t.
… On Oct 12, 2017, at 13:58, Paul Melnikow ***@***.***> wrote:
Sounds good!
prezto-inactive-community-fork/prezto#64
Sure, sorry for the delay!
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I'd like to see someone from this project be an owner of this repo, not just @nicoulaj, just in case we need something done to the repo. I'd be very comfortable with that owner being @belak as someone who is both technically competent and emotionally stable/tactful during disagreements. Personally, I am not a fan of the auto-update function. As long as our project culture is welcoming of those who are willing to learn, I don't mind if our barrier to entry requires that users do the research to get comfortable with Along those lines, from a philosophical standpoint, I am very leery of |
Hear, hear! |
|
Thanks for the kind words. :) I didn't want to put my name up there without someone else bringing it up because it just seemed a little bit like a power grab. @jeffwidman I don't think auto-update is something we should support, but a function which makes updating easier (similar to what we have now) which supports additional module repos would be worthwhile. Additionally, avoiding feature bloat in core is one of the reasons I'm pushing fairly hard for the contrib repo. I think most of us are in agreement on reasons for this. We've had a number of potential contributors leave because they weren't happy with the barrier of entry here and there are still a ton of pull requests sitting there which want to add a new module or a new theme... both things I'd like to avoid if possible in the future. Moving smaller/unmaintained features into contrib lets it be updated separately from core... and it makes it easier for us to move towards actual releases rather than just having everyone run from master. |
|
Agree with everything @jeffwidman said. |
|
I've set up a temporary contrib repo at https://github.com/belak/prezto-contrib where I'll be merging module PRs and getting it ready. It's public, but if you're interested in helping out, let me know and I'll see about getting you added. It's a massive pain, but if you do merge modules in, please make sure to use the original author in the commit. Also, I don't expect it to be stable for a while, so I might allow history rewriting on master for a little bit (this will definitely be disabled when it gets moved to a more permanent location) so it doesn't get super out of hand right away. Finally, if you'd like to help test any of the new modules, simply clone https://github.com/belak/prezto-contrib to |
|
Cool! Just to confirm, if I submit my modules to your |
|
I'm currently planning on transferring that repo as soon as we find a more permanent home, so any PRs submitted there should be transferred over. Also note that I'm not currently making any guarantees of stability for the contrib repo - at least not while it's sitting under my user. There's still a lot to figure out and I don't want to worry about compatibility while we're trying to get this off the ground. |
|
I was directed here by @belak giving feedback on #1002. I will say in general I don't like splitting git repos. It creates more problems than it solves. "Bloat" of a few hundred kilobytes on disk that doesn't affect prezto in any other way, should not be a major consideration. I think a "contrib" directory and tag on github issues can solve all the same problems, with fewer headaches and zero impact on anyone not using contrib outside of aforementioned tiny disk space. Most likely that ship has sailed though. So, I guess I have two main concerns about this. The first is that there need to be really clear guidelines about what goes where, what the guidelines are for which module goes into which repo. And if a module is in rough shape but desirable for core, if it is preferred typically for it to go "through" contrib, and then into the main repo, or simply to force it to be fixed up and then into main. To give what I submitted as an example: IMHO, a clipboard module most definitely should be in core, and not in contrib. Being able to copy/cut to the system clipboard or paste from it is hardly an exotic requirement; pretty much everyone likes this and there is almost no downside to it. It's likely to be useful to far more people than many (most?) of the modules currently in prezto. Of course, that is just my opinion, but that is why having clear guidelines is so important, so at least we know the criteria. The second is that I feel rather strongly that in the very near future (i.e. before you expect people to actually start using it), that the contrib repo should be a submodule of the prezto repo. This is important so that any synchronization that is necessary between the two repos is handled by the repos themselves, instead of by users. If e.g. there is a module API breaking change in prezto, the work can be done in both repos at once and then then committed correctly. If you want to be able to move modules from one to the other, this is also important. Forcing users to deal with this sync themselves would be a pain and probably be enough to cause me not to bother cloning into contrib. On a semi related note, prezto should provide a way to add to the "module search path" (probably via an env variable) so third party modules can be loaded up easily, while minimizing changes to prezto itself. @jeffwidman basic familiarity with git just isn't enough to reasonable maintain an up to date customization of prezto. Almost all customizations have to be done as commits into the repo in a very intrusive way. Even adjusting theme colors (a topic of another issue I opened recently), we are basically encouraged to copy the theme out and make adjustments. I recently updated my prezto fork; I had about 20 commits. Almost everything was very simple, minor customizations. To get this properly and cleanly rebased on the head of prezto took an hour or two in git easy, plus another couple of hours re-figuring it out how to do my basic customizations with the changes that had been made meanwhile. Just food for thought. Prezto is quite amazing overall and I'm very happy, but there's no doubt that for me this is its weak point (compare to say Spacemacs, which has this issue quite well thought out, forking Spacemacs to customize is not necessary). |
|
@quicknir I've included my thoughts below as well as why the plans are currently what they are. There's been a bit of discussion behind the scenes and I'm not sure all of that came across in the issue description. We do appreciate other point of view though. It's definitely possible that we missed something.
I agree. I general I avoid splitting repos like this as well. However, we are doing this so we can provide a well maintained core along with a slightly more unstable set of user written modules. We don't want everything in core so we can avoid what happened to oh-my-zsh. Additionally, we don't have access to add more contributors to this repo (Only Sorin does) and there are different expectations about what goes into core vs what will go in contrib.
I also agree with this. This has been a slightly larger discussion in #1424. The current plan (to avoid arguments) is to only allow modules in core which are "sponsored" by someone with commit access to the repo - someone who's willing to support that module when issues pop up. Everything else can go in contrib.
My opinion on this is that it would be on a per-case basis. I would like to get the clipboard module in core, but I think it currently fits better in contrib (for now) because I'm not 100% sure what needs to be done to get it working with both keymaps. If it supported emacs and vim and had a good README, it would probably be ready for core (I'd even be willing to support it in the future - I've just got quite a few other things on my plate right now so I don't know when/if I'll have the time to add emacs keybind support). Generally, I'd like to see most modules get added to contrib first. Most new modules have a bit of churn and I'd like to get that out of the way before moving them into core. Once they're stable, not changing a ton, and have someone who's willing to support that module, it makes sense that they'd be added to core.
This is a valid point... and one that I hadn't considered in this much depth before, but I think it makes sense (though not for initial support). I think adding contrib as a submodule is a good idea for when we move to official releases. Then the master branch of contrib could just target the latest stable release.
This was done in #1458 as a precursor for adding support for a contrib repo (see https://github.com/sorin-ionescu/prezto#external-modules for basic info on how to use it).
Another point I agree with. I hope to see external contrib repos popping up in the future as well. The framework was just put in place to make this possible. I already equate spacemacs' layers to our modules, so allowing external modules is a big step in the right direction. |
|
Have you considered going in an opposite direction, and instead of creating a repo hosting all possible plugins, creating an organization Consider oh-my-zsh, it hosts lots of modules, but they are unusable outside of it. If I was to use one of their modules, I'd have to clone the entire repo, or (what happens in prezto today) copy-paste their code and forget about receiving updates. Now consider some of the plugins in prezto, which are actually just a submodule of a separate standalone repo. Updating is as easy as updating a submodule, and the standalone module is useful not only in prezto, but in many other frameworks/plugin managers. Isn't it nice? Another benefit would be a more gradual write access, instead of giving multiple people write access to everything, you could have per-module maintainers with write access only to that one repo. I'm not sure if Github supports this, but I would assume it does? |
My personal opinion is that zsh doesn't need another plugin manager. There was a little bit of talk around officially endorsing another plugin manager in the community fork, but we actually decided against it to avoid locking users into a choice like that. The contrib repo aims to be a middle ground. The requirements will be much less strict than here so much more will be accepted, but everything will be in one place. I'm hoping it will also help increase visibility of these plugins, even if it's just directly loading an external module.
As a counter point, a number of plugin managers have direct support for loading modules directly from oh-my-zsh. That's the advantage of having a centralized system.
This is nice. I'd honestly love to see more of these plugins added directly into the contrib repo as an external dependency, so users can just clone contrib and know they're getting a plugin that should work well with prezto.
Github doesn't support this and the only person with admin access to this repo is Sorin. We're also trying to respect Sorin's wishes that only a very select number of modules make it into core since it is his repo. |
Except prezto itself 🙂 So I want to use a few modules from oh-my-zsh, am I encouraged to copy-paste them into prezto-contrib, or I must install a plugin manager that supports oh-my-zsh? |
|
Touché. Personally, I'd like to avoid wholesale copying of plugins since that technically means we'd need to include the copywrite notice from OMZ with each of those plugins and OMZ has a tendency to do things very differently than prezto. My personal (unofficial) recommendation is to port over anything you're willing to maintain (note that I said port, not copy) and to use a plugin manager of your choice for anything else. I don't even use the official runcoms unless I need to test issues. https://github.com/belak/dotfiles/blob/master/zshrc#L33 |
|
To be blunt, anyone who suggests a scheme with that many submodules has either far too much or too little experience with git. |
I used to work on Bitbucket Cloud, if that explains anything. 😆 Submodules can be useful when they're used correctly, and how prezto uses them (to point to external repos for explicit dependencies) and in extension how we'll use them in the contrib repo should fall into that bucket. |
|
Hah, no I'm fine with your suggestion. But suggesting one sub module per prezto module is madness. You don't want to scale O(N) in terms of submodules... |
|
Well... I simply see the same plugins copy-pasted all over internet, in oh-my-zsh, in prezto, in zim, and every time I think "oh god, why doesn't someone put it in a separate repository, so that prezto and all others can simply point to it". What if someone decides to improve a plugin? Chances are it will be fixed in oh-my-zsh and years later it will be discovered that prezto's copy is out-of-date. |
|
Yep... prezto was originally forked from oh-my-zsh and I believe zim was originally forked from prezto. Each of the authors had different ideas on how they wanted to do things. Plugin managers for zsh are comparatively recent... and things might have turned out very differently if they had existed when oh-my-zsh or prezto were started. |
|
I've just tried antigen, works quite well I must say. Maybe what you mentioned as a personal unofficial recommendation should become official? Don't merge copy-pasted modules from oh-my-zsh unless there is a reason to do so, promote using plugin managers. This would be at least small step towards reducing code duplication all over internet. |
|
Does anyone have ever used git subtree instead of submodules ?
It seems to be a nice alternative. But I can't say much because I have
never used it myself.
https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
Em 28 de nov de 2017 23:37, "Maxim Baz" <[email protected]> escreveu:
I've just tried antigen, works quite well I must say. Maybe what you
mentioned as a personal unofficial recommendation should become official?
Don't merge copy-pasted modules from oh-my-zsh unless there is a reason to
do so, promote using plugin managers. This would be at least small step
towards reducing code duplication all over internet.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1483 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALwvjUF5-wQrj-vBMqIOXO8F8o8TlA9ks5s7LU8gaJpZM4PzCX1>
.
|
|
I've used it, but it's somehow more complicated to set up and use than submodules. |
|
I support the idea of a contrib repo curated by prezto admins being implemented here. I also have championed the idea of plugins maintained by separate authors, using a module convention that is portable to prezto, OMZ, zim, and zulu. That's certainly better than continually porting features back and forth. It's also a good way to consolidate maintenance, and deal with the maintenance bankruptness which is OMZ. Meaning: if a popular OMZ plugin is pulled into a separate repo and maintained there, even OMZ users could load it if they choose. Some plugins necessarily won't be portable. These may be good candidates for the contrib repo. It's also a good way to get community maintenance for plugins which have been abandoned by their author.
IIRC that decision was made after the community fork shut down. The argument against plugin managers wasn't about lock-in, rather that it basically breaks any kind of interoperability guarantee. There's no reason prezto couldn't support multiple plugin managers.
I've worked the most with antigen, and know you have too. I'd tend to recommend it. In my experience the author is responsive, caring, and knowledgeable. I built prezto "patches" for both antigen and I think also zplug, though I gave up on zplug because they weren't very responsive. |
|
I'll look at adding support for OMZ style plugins (#1484) later this week to see about making it easier to load external plugins in module dirs. |
I'd like to begin slightly more official talks on creating a contrib repo. I've been in talks with @nicoulaj to see about creating one under the @zsh-users umbrella, but it would be good to get as much figured out as possible before hand.
Purpose
There's a bit of a question about what to do with new modules and themes when they are submitted to this repo. There are multiple modules (and themes) which are pretty much ready to go which haven't been merged to avoid prezto-core getting bloated. The goal of adding a contrib repo is to add something with a much lower barrier of entry to make adding modules and themes much easier without bloating up this repo.
Collaborators
These are all the collaborators on this repo I know of. We would start with these on the contrib repo and possibly add additional collaborators later.
I'm not sure who we'd have as the administrator of this repo. Maybe it would be left as only @nicoulaj, or maybe we'd add one or more of the collaborators. This is definitely open for discussion.The current plan is to have both @nicoulaj and @belak as administrators of the contrib repo. Other contributors could be added in the future if necessary.
Temporary Contrib Location
I've set up a temporary contrib repo at https://github.com/belak/prezto-contrib where I'll be merging module PRs and getting it ready. All the collaborators listed above have been added as collaborators of the contrib repo.
Things Left To Do
:prezto:load:pmodule-dirsThe text was updated successfully, but these errors were encountered: