The Need, the Goal...

By "project-based config" I mean a project contained in a git repo that contains all the vim configuration -- vimrc and plugins and colorschemes -- right there in the repo. In my case this is in the repo's .config directory.

So: cd path/to/project && vi -u .config/vimrc some-script.py should... somehow ...load all the plugins/colorschemes contained in that .config directory, ignoring the standard ~/.vimrc and ~/.vim/* config files.

Possible Strategies

  1. Plugin manager:
    • vundle
    • pathogen
    • vim-plug
  2. a plugin made for this
  3. manual configuration
    • perhaps has multiple ways it could be achieved?
  4. magic:
    • vim considers ~/.vimrc and ~/.vim/ to always be siblings so if you do vi -u path/to/config/vimrc since vim is smart it will automatically look for plugins inside path/to/config/vim
  5. something else?



  • #4 doesn't seem to exist.
  • #2 doesn't match my criteria, as "an automatic way of sourcing vimrc from current directory" is a different use-case, I don't want automatic, it should require explicit intention by invoking -u or something comparable.
  • #1: I've used pathogen for years, but I'm not sure if it's even capable of this. I tried using vim-plug and could get that working in the same way pathogen works (with standard location of config files) but couldn't get it working for this use case.
  • #3 I've spent hours reading :h packages, :h packpath, :h runtimepath, and trying to derive a solution from them but nothing yet works. The trouble here is that :h packages is not clear about the distinction between foo and foobar in the context of a plugin that we find off Github (it describes unzipping individually zipped files). Not a single plugin has I've seen has a start or opt directory, but it says to manually create that, though it's not explicitly clear about "where"... so just guess, and try every option! I did this to no avail. Additionally, :h packpath is not helpful and :h packages has no mention of it... but these two things might need to be used in tandem(?).

2 Answers 2


There are two related options: packpath and runtimepath.

If you set packpath then all plugins sub-trees must reside under pack/<bundle>/{start,opt} to comply with :h packages.

If you set runtimepath directly then you must add every separate plugin subtree to runtimepath (and then also runtime! plugin/**/*.vim manually in case you have any). Also, you'll probably want to have --noplugin or set noloadplugins to disable auto expansion.

And last but not least, use valid VimScript only: only some commands accept arbitrary expressions. set is not one of them (consider that we write set xyz=foobar and NOT set xyz="foobar").

  • What does start and opt mean? Do I need to manually create those directories and then move the plugin-name.vim file into it? I've read :h packages and that point is not explained.
    – alec
    Sep 2, 2021 at 20:49
  • Can you give an example of usage? From inside this project directory I'm doing vi -u .config/vimrc script.py and I'm trying to put the packages in that directory's .config/vim/packages but putting in that local vimrc this line set packpath=.config/vim/packages doesn't do anything. Plugins in that directory cannot be found when vim loads.
    – alec
    Sep 2, 2021 at 20:58
  • Plugins in the start directories load upon starting Vim. Plugins in the opt directories only load when call by the packadd command. See :help packages for all the details. Sep 2, 2021 at 22:02
  • what's that have to do with <bundle>?
    – alec
    Sep 2, 2021 at 22:05
  • Everything is explained at :h packages. Read it from beginning to the very end as many times as it takes to understand.
    – Matt
    Sep 3, 2021 at 19:18

For a manual method, packpath can provide a solution (using only a single line of code in the vimrc file) with the following constraints:

set packpath=.config/vim will allow you to put plugins inside .config/vim/pack/*/start/ (as well as .config/vim/pack/*/opt/) and this will work when invoked like vi -u .config/vimrc scriptname.py.

But when in a subdirectory of the project that packpath value won't work; if you're doing vi -u ../.config/vimrc data.json then the plugins will not load. So you either need to:

  • know the full path and hardcode the location like set packpath=~/path/to/project/.config/vim
  • write some vimscript/etc to trace through parent directories to somehow identify the location (based on your project's unique structure) of the vim config, and then do executure ':set packpath=' . yourVariable since set can't take variables on its own.
  • or, if you can accept this limitation, just always invoke vim from that project root

Once you've done set packpath in your project-specific vimrc, then you can add as many plugins you'd like...

:h packages says

"When Vim starts up, after processing your .vimrc, it scans all directories in packpath for plugins under the "pack/*/start" directory."

So if packpath=~/path/to/project/.config/vim then you can:

  • place plugins inside one big ...pack/bundle/start directory like:
    • ~/path/to/project/.config/vim/pack/all-plugins/start/plugin-1-dir
    • ~/path/to/project/.config/vim/pack/all-plugins/start/plugin-2-dir
    • ~/path/to/project/.config/vim/pack/all-plugins/start/plugin-3-dir
  • or you can be more specific and do:
    • ~/path/to/project/.config/vim/pack/plugin1/start/plugin-1-dir
    • ~/path/to/project/.config/vim/pack/plugin2/start/plugin-2-dir
    • ~/path/to/project/.config/vim/pack/plugin3/start/plugin-3-dir
  • and if you don't want the plugin loaded right when Vim starts then you can use opt directory instead of start like ...pack/anything/opt/plugin-4-dir.

plugin-1-dir, plugin-2-dir etc is just the name of the plugin from when you git clone it (or however you get it), and the file/directory structure that the module comes with can be used as-is without modification.

Your Answer

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

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