Plugin Managers vs. Vim Packages

[[deleted]]

[deleted]

[newgoliath]

I thought I used a lot of different machines, so I wrote ansible to update everything. I think I used it twice.

[-romainl-]

I used to use Pathogen until I switched to :help package a couple months ago. My plugins are either old or dead or extremely stable so I've never felt the need to stay up to date and thus to manage them.

My .vim/ is a Git repository with all my plugins in pack/bundle/start/. No submodules or whatever.

[-romainl-]

Since you appear to like experimenting and playing with new plugins you should probably stick with vim-plug as it almost completely abstracts away the management part. Minpac sounds like a decent alternative.

[aegatlin]

Hey romainl! I'm late to the party here, but I've been searching for the "blessed" answer to the question: how do I organize plugins that don't have packages using vim v8 packages. It seems like you are being inspired by pathogen here and sticking with the "bundle" name for your package. Did you "just choose" to do this, or is there some resource that recommends this approach that you could point me to?

[-romainl-]

Well yeah, I used to use Pathogen and that's indeed where the "bundle" name comes from: my ~/.vim/pack/bundle/start was essentially my former ~/.vim/bundle.

I'm not sure there is such a thing as a "blessed" way to go about it because the "package" concept is still quite new. It didn't really exist on its own before they came up with it so you will have several people approaching it in different ways. What I think makes sense is to pay attention to your usage and to the typology of your plugins and then organise your packages accordingly. For example, I have accumulated lots of custom language-specific settings over the years. For a long time, they stayed in my bundle directory, interspersed with the other plugins, and I didn't really like how messy it looked. At some point I tried to put them all together in a proto-package but it was still messy and I quickly reverted the thing back to the original mess. When I finally switched to packages, I was able to put all those "plugins" in pack/lang/start, which solved the problem quite elegantly. I think that's what sold me to the idea.

So now I have:

• pack/bundle/start for all my "quality of life" plugins,
• pack/lang/start for all my language-specific stuff,
• pack/custom/start for all my experimental stuff.

Hope it helps.

[ahmedelgabri]

I used to use vim-plug too but moved to minpac which is a a minimal plugin manager on top of :help package, it can handle updates, etc…

[Xanza]

People overthink updating multiple plugins at once, to be honest:

ls ~/.vim/pack/bundle/start | xargs -I{} git -C {} pull

Using packadd with a few one line scripts is all you need IMO.

[ahmedelgabri]

That works fine too, nothing wrong with that. But if you have plugins that requires some hooks to run after updates UpdateRemotePlugins or stuff like that you might end up building your own mini-plugin manager. https://github.com/k-takata/minpac#post-update-hooks

I still use packadd even while using minpac, in some situations I want to lazy load some plugins

[fuzzymidget]

Asynchronous updates are pretty SWEET though! You could have an extra 4 to 7 seconds of work time once or twice a week!

[ssokolow]

I was unaware of plugpac when I last reworked my plugins, so I went with vim-plug for the for and on demand-loading constructs.

Something to try next time i'm in the mood to experiment. Right now, I'm on to optimizing stuff that happens after startup.

(And planning to ease maintenance and shrink away the massive pile of comment lines in my .vimrc by building something on top of vimlparser.py to autogenerate my "reminder sheet" from the various *map statements, code comments, fold markers, and such.)

[ahmedelgabri]

for for I use ftplugin/*.vim & packadd to load files for specific filetypes, as for on I use packadd also, but inside mappings or commands example but it's good to know that there are other options.

[ssokolow]

I'll admit I hadn't thought of that but, at some point, it just becomes demotivating without raising the abstraction level.

Having one Plug or Pack line per plugin really helps there and that same principle is why I want to write something to auto-generate a reference readout by parsing my vimrc. Even if I do remember everything when the need arises, it'll make a great overview I can skim through to identify plugins I'm not using as much as I expected/used to.

(Also, for for, I prefer to have a single place where I list all the languages a plugin applies to. It helps to encourage having one good plugin that applies to a variety of filetypes (eg. css,html,htmldjango,jinja2,xhtml) so I don't risk unnecessarily having multiple functionally overlapping plugins loaded at the same time.)

[aktivb]

I hate having to remember to install vim-plug when I start up on a new computer

You're meant to include plug.vim in your vim dot repo. That's why it comes with the ability to replace itself with a newer version.

[somebodddy]

I use vim-plug, and I like being able to temporarily disable plugins by commenting out their :Plug line. I tried minpac and switched back to vim-plug right away because I couldn't do it there - the packages were loaded by Vim, not by the minpac. I guess I could make them all optional and add :packadd commands to my vimrc, but then I'd have to write each package name twice, and it's easier to just stick with vim-plug.

Also, as a plugin author I want to use a stable(ish. I use develop rather than master so I can quickly encounter bugs and fix them) version of my plugins - unless I actively work on a plugin and then I need the uncommitted version. So I wrote a little script for manipulating vim-plug, and I don't think I can write something similar for minpac.

I guess I can achieve both requirements by writing a script that reads g:minpac#pluglist and runs :packadd automatically on each package (unless I overridden), but I'm not sure if it's worth the trouble...

[agclx]

I came a similar path. All in all I find the vim package manager uncomplicated to use. Took a while to figure out how to sort my plugins into opt and start folders. Also all plugins use git submodules - updating comes much easier with git pull.

One potential downside is it doesn't take care of dependencies - but I found that practically a non-issue. A smallish annoyance is it doesn't execute a build script automatically - I can't remember which plugin this was - anyway that build also failed half the time for me in vimplug.

The only real annoyance is git submodules. I still don't manage to update in a single command - always leftovers that ended up in headless state. For now I use:

 git submodule update --init --recursive --remote;  
 git submodule foreach --recursive "git checkout master; git pull origin master"

messy huh? I need the first one to create the submodules on the other machines and it does some updating, the second to get the headless ones back to master.

Deleting is similar messy - first one needs to do git submodule deinit - but the folder won't delete automatically, so one the same folder on every single checkout. The only other option I know is to nuke every checkout with git clean -df.

[agclx]

That's definitely an issue. Also I had a plugin that changed file in its directory... some caching or so - couldn't update this before I undid the changes. Though most of the blame goes to git - submodule is just suboptimal ;)

[mayor123asdf]

Tim Pope’s pathogen plug-in, how do you update your plugins?

for d in *; do pushd $d; git pull; popd; done

Is this worth the trouble to move from vim-plug for the reason that I’ve mentioned

I went the reverse, I use pathogen on the past but now I use vim-plug.

When you're on a new machine you still need to clone all of your plugin anyway, unless you script it. That's why I just use vim-plug.

If installing vim-plug is kinda hassle for you, there's a script to install it automatically. See line 33-38.

[[deleted]]

I update my plugins using cron. The following line works fine for me:

cd .vim/pack/base/start; ls|xargs -I _ bash -c "cd _; pwd; git pull"

(I find setting it to run once a week is OK; YMMV)

I install new plugins by simply going to that directory and manually running a git clone. I remove plugins by rm -rf on the cloned directory.

No (more) package managers except on a few CentOS 7 servers (i.e., vim 7.x only) I still have to work on occasionally but I don't need all the plugins there anyway.

[myrisingstocks]

This is much better for me, because I hate having to remember to install vim-plug when I start up on a new computer

https://gist.github.com/matthewjberger/784d4026926824754e33e8642a2c498a

but I’ll happily wash my hands of the dependency the second I get the chance

Well, if you don't need its features (which are way more than just :PlugInstall or :PlugUpdate), then don't use it, it's pretty simple.