plug.kak

plug.kak copied to clipboard

While discussing https://github.com/dracula/dracula-theme/issues/644 , I realized that there can be conflicts between plugins with the same "basename", but different URLs.

Do we have a way to handle this? BTW, how's v2 of plug.kak coming along?

No, plug.kak doesn't have any way of handling this. This was suggested in #14 but never implemented.

Probably the ideal way would be to use reverse-domain grouping, e.g. to put plugins into com/github/user/repo, com/gitlab/user/repo, and so on. This would fully solve the problem and is something other package managers do.

This still needs to be thought out, and also should not break load-path usage

An aside: while working on caching sed-bin, I've realized that a Linux filesystem allows you to use any string that doesn't contain NULs, and turn it into a path. For example, http://example.com/my/plugin is usable as a path: it is the same as http:/example.com/my/plugin. This causes problems if you have to interoperate with Windows and other OS's with filename restrictions, of course.

However, more simply, it might also be possible to have a dir parameter to plug, which gets passed to git clone. Not sure what other changes this would entail.

In kak-bundle, I've allowed URLs to be substituted with arbitrary "installer" shell commands. There's an installer2path function which translates between installers and sub-folders of plugins/ (it takes the component after the last / in the URL or command). Installers can be simple URLs, full git clone URL ./renamed-dir, ln -sf /path/to/plugin [./optional-rename] (this emulates load-path) shell commands, or anything that creates a dirname matching the last /component of the installer.

Yes, this needs to be fully thought out (which is why I've asked about v2 — it may not be wise to invest too much effort in v1).

Yes, this needs to be fully thought out (which is why I've asked about v2 — it may not be wise to invest too much effort in v1).

Wait, we're already v2. The rewrite happened here https://github.com/andreyorst/plug.kak/tree/v2.0.0

Ah. I was under the impression that there was going to be a huge rewrite in the way config files are generated... or something, from a discussion I can't quite recall.

So, anyway, there won't be any paradigm shifts anytime soon, I take it.

However, more simply, it might also be possible to have a dir parameter to plug, which gets passed to git clone. Not sure what other changes this would entail.

The main issue here is that this basically needs to be available for all other commands, like plug-clean, and so on. Right now they deduce the path from the repo URL. Passing such parameter to plug will result in a problem similar to #113

I think that getting rid of domain keyword and forcing full URLs for anything other than GitHub would solve most of these problems. Because I believe that right now domain would cause #113 as well. However I don't like the fact that GitHub is the defacto hub for plugins, and this is partially addressed by the plug_git_domain but it's a bit cumbersome.

Ah. I was under the impression that there was going to be a huge rewrite in the way config files are generated... or something, from a discussion I can't quite recall.

So, anyway, there won't be any paradigm shifts anytime soon, I take it.

No no, it's not like we can't release v3 spontaneously including another major rewrite or incompatibility changes if there is enough desire and changes to back it up.

I remember I've said that the config file generation can be improved if the current one had some significant disadvantages, but I don't see any as of this moment.

One thing I still want to do is to make it so plug.kak will have an option to skip rebuilding on each launch, in a case when you're not changing your configuration constantly. This should speed up the startup even further, as it will be a matter of loading all files from the build directory without any other things to do. And the rebuild may occur for plugins not found in the build dir, or after a successful update. I'll open a ticket for this, so I won't forget to implement it.

However, more simply, it might also be possible to have a dir parameter to plug, which gets passed to git clone. Not sure what other changes this would entail.

The main issue here is that this basically needs to be available for all other commands, like plug-clean, and so on. Right now they deduce the path from the repo URL. Passing such parameter to plug will result in a problem similar to #113

I think the "last-/-component" logic I mentioned above would also work here, and you could also allow full shell-command installers (git clone ..) besides simple URLs. Installers are identified by the presence of whitespace (if the "URL" has whitespace, it's actually not a URL but a shell command to be executed; if it doesn't, it really is a URL and it needs to be wrapped in git clone).

This is quite practical, and works in kak-bundle, but it lacks a bit on elegance.

One thing I still want to do is to make it so plug.kak will have an option to skip rebuilding on each launch, in a case when you're not changing your configuration constantly. This should speed up the startup even further, as it will be a matter of loading all files from the build directory without any other things to do. And the rebuild may occur for plugins not found in the build dir, or after a successful update. I'll open a ticket for this, so I won't forget to implement it.

Currently (after the "avoid mkdir" merge) this would only save a rm external command call (which actually might make a big difference since it's again one of the few external calls left).

Now that I think about it, it's not even necessary to call rm, you can just > $file to make it empty. There are [ -e $file ] checks — those could be translated to [ -e "$file" ] && [ -s "$file ] (zero-size test builtin)

Another, probably a bit extreme solution, would be to fork the needed repo, set up mirroring, and rename the fork :smile:

FYI I've started working on this on the reverse-domain-grouping branch

Will this be toggle-able though? One thing I like is that I can share both my plugins folder and my kakrc between plug.kak, kak-bundle, and soon probably cork.

I'm not sure how complicated it would be to make this grouping optional, though.

No, this will not be toggle-able. The internal structure of the plugins directory should not be exposed to the user, as it is just an implementation detail, and the fact that right now kak-bundle works with it is a lucky coincidence (unless it was intentional by the author to make migration easier). But, the way how plugins directory is structured is not in a public API of any sort, so other tools should not rely on it staying the same.

I'm also thinking that a true reverse domain grouping is a bit too much for this, we can get away with just creating directories like github.com/, gitlab.com and so on, and put plugins into user directories. So the resulting structure of plugins would be something like

.build/
github.com/user1/repo
github.com/user2/repo
gitlab.com/user1/repo
...

I'm not sure yet where I should put the .build direcotry, as it can either stay on the top level, and contain the same layout as plugins or can rest in every service dierectory. No sure on that, though.

the fact that right now kak-bundle works with it is a lucky coincidence

It's more like plug.kak was already there, git clone URL seems the most obvious and easiest to implement, so the other 2 managers followed lead

I'm also thinking that a true reverse domain grouping is a bit too much for this, we can get away with just creating directories like github.com/, gitlab.com and so on, and put plugins into user directories. So the resulting structure of plugins would be something like

As I mentioned above, every URL functions, as-is, as a filesystem path... Paths need to be sanitized though (NTFS), so the URL has to be processed. Of course, the more sed's you involve in this processing, the slower plug becomes, and the more pure-sh code you involve, the more fragile it becomes.

There's also the added problem that you have to deal with user@host:PATH (which I see is only implemented for git@ — time for another issue) and ext:: URIs...

.build/
github.com/user1/repo
...

I'm not sure yet where I should put the .build direcotry, as it can either stay on the top level, and contain the same layout as plugins or can rest in every service dierectory. No sure on that, though.

If doesn't save rebuilding, it doesn't really matter. If it saves rebuilding, you can even put individual .build's in github.com/user1/repo/.git/.build (yes really, inside the .git folder, where it they don't look like untracked files).

As I mentioned above, every URL functions, as-is, as a filesystem path...

Yes, but it is quite cumbersome to maintain. Also while git@github:foo/bar.git is a valid path, it's not something I'd like to have, as it would conflict with github.com/foo/bar.git on load, so these two should resolve to the same directory, as these are the same URLs.

There's also the added problem that you have to deal with user@host:PATH (which I see is only implemented for git@ — time for another issue) and ext:: URIs...

The more and more I think first arg should be a fully qualified URL, but that would be a hard breaking change for a lot of users.