I'm trying to understand how the packages feature in Vim 8 works. The documentation suggests doing the following:

    % mkdir -p ~/.vim/pack/foo
    % cd ~/.vim/pack/foo
    % unzip /tmp/foopack.zip

 The directory name "foo" is arbitrary, you can pick anything you like.

In this example, what is the point of the foo directory?

I plan to use the packages feature in much the same way that I used pathogen. For my purposes, I can install plugins like this:

mkdir -p ~/.vim/pack/bundle/opt
mkdir -p ~/.vim/pack/bundle/start
cd ~/.vim/pack/bundle/start
git clone [email protected]:tpope/vim-unimpaired.git
git clone [email protected]:tpope/vim-fugitive.git
git clone ...etc...

Following the convention in pathogen, I've used the name bundle for the directory. I can then install all of my plugins into the ~/.vim/pack/bundle/start directory. If for some reason I want to install a plugin that I use only occasionally, I can put it in the ~/.vim/pack/bundle/opt directory.

Is there anything to be gained from creating a sibling to the bundle directory? It feels to me like this level in the directory tree is unnecessary, but I'm assuming that it's there for some reason.

  • I thought about it too. Seems like the only reason is to give the option of how to name it. Apr 3, 2017 at 11:28
  • 1
    If there's no reason to ever create a sibling to the bundle directory, then I'd prefer that level of the directory tree to not exist at all. "What shall I call this directory?" is not a freedom that I want - it's just another cause for decision fatigue!
    – nelstrom
    Apr 3, 2017 at 11:44

2 Answers 2


Yes, you can have multiple pack directories

In the example you quote from the documentation, "foo" is the name of the package.

In your example, you've created a single package named "bundle". You could indeed create other subdirectories of the pack directory: each of these would be another package.

There's not necessarily any benefit for you to create any siblings to bundle, but that doesn't mean the entire level is unnecessary. The idea is that a single Vim package can contain multiple plugins (which might depend on each other). The entire package can then easily be installed or removed with a single action.

For what it's worth, I'm not personally aware of anyone actually exercising this aspect of the feature for anything useful, although like you I'd presume it was created to service an actual need some users have, and not just for the purposes of hypothetical flexibility. Maybe at some point in the future the de facto standard would be for even single plugins to be distributed as packages, making your "bundle" directory unnecessary.


Having done a bit more reading and thinking about this, I'm posting an answer to my own question.

A plugin contains one or more .vim files which add new functionality globally or for a particular filetype. Plugins are usually organised using one or more of these subdirectories:

plugin    -  global commands/mappings (loaded on startup)
ftplugin  -  ftplugin functions (loaded for the specified filetype)
autoload  -  library functions (loaded lazily)
doc       -  documentation

A package contains one or more plugins. :h package-create shows how to create a package. Packages are organised using these subdirectories:

start  -  for most plugins, loaded on startup
opt    -  for optional plugins, loaded when user runs `:packadd`

You can have as many packages as you like. The only constraint being that each one has to have a different name (since sibling directories can't have the same name).

It's possible to publish a package that contains a set of related plugins. I can't find any such packages on GitHub, but maybe these will emerge over time (the packages feature hasn't been around for long). At the same time, it's perfectly valid to build up a single monolithic bundle package for personal use.

I've started to use minpac to manage the plugins in my package and I'm liking it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.