Feature request: Plugin not in root of repository

[savq]

Feature request: Plugin not in root of repository

[savq]

Unfortunately, this isn't a feature that I'd be willing to add to Paq.

Using neovim's built-in package system, and not modifying the runtimepath was one of the motivating factors to write Paq in the first place.

The projects you linked to are, as you said, not (neo)vim specific. I'd recommend you symlink the vim-related directories to a different pack/ directory. See :help packages.

For example, with Black:

$ pip install black

$ pip show black   # this will show the location where Black is installed

$ cd ${XDG_DATA_HOME:-$HOME/.local/share}"/nvim/site/pack/" # Go to the directory where Neovim expects package collections

$ mkdir local_plugins    # Create your own directory for local plugins

$ cd local_plugins

$ ln -s path/to/black/

Neovim will append directories in pack/*/ to the runtimepath automatically.

I know this isn't a smooth workaround, but having a neovim package manager download Python dependencies seems like a terrible idea tbh. Letting pip (or conda or whatever) do the work and version handling will cause less trouble in the long run.

[savq]

The runtimepath rule doesn't exist because it's important (it's not, modifying the runtime was the way Pathogen worked). It's simply there to mantain a somewhat consistent scope for the project.

Symlinking in unix systems is easy (that's why I suggested it), but not that simple in Windows iirc. And Windows support is something I kinda already commited to 😕. It's more a matter of trade-offs, you know? Paq has a simpler feature set, that works well with nvim 0.4 and windows. Packer does have configuration for runtime directories, and might be a better fit for your use cases.

[dashavoo]

Interesting, I hadn't realised what vim-plug's rtp option stood for.

That is fine, but just for clarity: I think I picked a bad example with black. I agree neovim managing Python dependencies is a bad idea. I was hoping for support for non-standard repository layouts. In the first example I gave the vim/ subdirectory is what I actually wanted Paq to use, discarding everything else.

[savq]

Yes, I understand. But there are only two ways Paq can use the vim/ directory. Either Paq is loaded at start-up to modify the runtimepath, or Neovim knows already to load the package, which can done by symlinking the package appropriately.

The point still stands, Paq doesn't have to be loaded at start-up, and add this feature also implies adding that requirement, which is not something I'm interested in, since it only really applies to these rare cases.

[bendk]

Is there a way to implement something similar without modifying the runtimepath?

Use case: I want Paq to install and manage the onehalf color scheme (https://github.com/sonph/onehalf). The vim-specific stuff is in the vim/ subdirectory.

What about adding a vim-root option? If specified then paq will:

• Checkout the repo to a different location (maybe paqs/repos/onehalf)
• Add a symlink at paqs/start/onehalf pointing to paqs/reops/onehalf/vim

Seems like a reasonable way to manage this without needing to modify the runtime path. The uninstall code would need to be altered to remove things from the repos directory as well, but that seems simple enough. The other corner case is checking when someone changes the vim-root value, in which case you'd need to move the directory and fiddle with the symlink. If this is something you're interested in adding, I could try writing a PR.

[MatthiasGrandl]

This one as well: https://github.com/soywod/himalaya/tree/master/vim

@savq would you be cool with the solution @bendk proposed?

[yochem]

Another possibility would be to:

1. ask the maintainers if they could divide the repository up in seperate repositories (and maybe use git submodules)
2. Create a repo, submodule https://github.com/sonph/onehalf, then ln -s vim/* to ./*