search

andreyorst / plug.kak

Plugin manager for Kakoune
MIT License
197 stars 18 forks source link

plug.sh: allow file:// URLs #84

Closed mralusw closed 3 years ago

mralusw commented 3 years ago

6-byte changeset. Allows to refer to local git repos without, seemingly, and so far, any complications as in the case of load-path (which I haven't been able to get to work for my purposes)

andreyorst commented 3 years ago

Hi,

We already have file support, although it is done with a different option to the plug command:

https://github.com/andreyorst/plug.kak#loading-plugin-from-different-path

I've made it that way because plug parses github-style paths as urls ("username/reponame") an supporting file urls here felt confusing, as users might expect it to work like "dirname/dirname".

I'm not strictly opposed to this change, as it makes file support explicit, but it makes load-path redundant, so a bit more refactoring needed, I guess

6-byte changeset. Allows to refer to local git repos without, seemingly, and so far, any complications as in the case of load-path (which I haven't been able to get to work for my purposes)

You can view, comment on, or merge this pull request online at:

https://github.com/andreyorst/plug.kak/pull/84 Commit Summary

  • plug.sh: allow file:// URLs

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/andreyorst/plug.kak/pull/84, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEUROTZPVQONOZPJYSXVZBLTTQ4PXANCNFSM466Y6F6A .

mralusw commented 3 years ago

I know you do, and I couldn't get load-path to work until I pushed my code to gitlab.

plug 'mru-files' load-path '/home/user1000/Projects/mru-files'

It would interpret 'mru-files' as a github repo. So OK, I pushed my code to gitlab. After that, every time I made a change locally it wouldn't update until I again pushed to gitlab. This makes local development kind of difficult, or maybe I didn't get the docs.

mralusw commented 3 years ago

I get the confusion about github / local paths. Perhaps plug.sh should check for explicitly supported URL schemes, see #85 (change the case statement to explicitly match e.g. http://*|http?://*|git://*|file://*, also *@*:* probably)

mralusw commented 3 years ago

Also, load-path wouldn't necessarily be redundant, if it worked properly; file:// only updates when the user commits locally, but with load-path, uncommitted / untracked changes should be visible as well.

andreyorst commented 3 years ago

I couldn't get load-path to work until I pushed my code to gitlab.

Hm, this is weird. I'll double-check this. It should not require any git repo in the dir at all.

Another thing to consider, is how file:// urls should handle updates? Plugins added with load-path weren't meant to be updated with plug.kak, as it can be an arbitrary directory wit no .git in it, or use a different version control system, so by adding a plugin with this option you're on your own. I feel that file:// urls should follow similar logic, which makes it the same thing as load-path.

mralusw commented 3 years ago

That's what I was saying (I think).

Isn't this the current load-path logic? There shouldn't really be a difference between a file:// URL mounted over NFS and a http:// URL

andreyorst commented 3 years ago

Orthogonally, a file:// URL (which can actually be backed by NFS, Samba, sshfs, bittorrentfs / pigeonfs / anything git doesn't need to care about) simply means to clone and update from there

Hm, I'm not sure what plug.kak should use to fetch from these when they're in samba? Or sshfs files, should it mount them for you?

mralusw commented 3 years ago

Hm, I'm not sure what plug.kak should use to fetch from these when they're in samba? Or sshfs files, should it mount them for you?

plug.kak doesn't need to do anything, just allow file:// URLs. The user can mount NFS, Samba, sshfs etc at any mountpoint, and then the plugin becomes file:///path/to/mountpoint/.../repo/.

In particular, sshfs mounts don't even require root (though that shouldn't really matter here)

sshfs my-host:shared ~/vol/my-host
git clone file:///home/me/vol/my-host/repos/project /tmp/project

It may look like a local filepath, but it may be connected only intermittently. One thing that does matter here: it seems plug.kak seems to always try to fetch, even if no plug-update is requested, I'm not sure how it handles network failures? A file:// URL can be just as disconnected as a http:// URL.

andreyorst commented 3 years ago

Then I don't see the difference from load-path. I'd rather fix it instead of adding file urls

mralusw commented 3 years ago

Then I don't see the difference from load-path. I'd rather fix it instead of adding file urls

The difference is that

andreyorst commented 3 years ago

load-path should see uncommitted / untracked changes, while file:// URLs (without load-path) shouldn't.

I don't understand this. load-path is not tied to git at all, it just a way to specify from where to source .kak files. It is not associated with Git whatsoever.

with a file:// URL (but no load-path), plug.kak should create a folder in ~/.config/kak/plugins that it manages itself and which is always available.

This doesn't make sense, because to manage a plugin plug.kak needs git, and file:///user/foo can be not a git repo. If you want for plug.kak to chreate an entry in ~/.config/kak/plugins then it should copy directory from that file URL, thus we'll need some protocol besides git clone to be supported in plug-install and plug-update to be able to fetch from these file urls.

andreyorst commented 3 years ago

I couldn't get load-path to work until I pushed my code to gitlab.

I think I've fixed this. I've tried by moving fzf.kak directory to ~/ and removing .git from it, and it loads correctly. Can you test if changes in the fix-load-path branch solve your issue with load-path?

mralusw commented 3 years ago

I don't understand this. load-path is not tied to git at all, it just a way to specify from where to source .kak files. It is not associated with Git whatsoever.

Sure, they're orthogonal features. That much we agree on I think. A plugin with load-path is not managed by plug.kak, whether it has a git remote or not, or is not even a git folder.

This doesn't make sense, because to manage a plugin plug.kak needs git, and file:///user/foo can be not a git repo.

Sure, just as http://kakoune.com is not a git repo (user error, their problem), or http://github.com/me/mine can temporarily return 404 or 5xx (network down, remote on maintenance). git clone and git update will fail if the origins are broken, temporarily or permanently. plug.kak doesn't need to special case anything.

If you want for plug.kak to create an entry in ~/.config/kak/plugins then it should copy directory from that file URL, thus we'll need some protocol besides git clone

It doesn't need to copy (as in cp). If the user specified a URL for the plugin, be it file:// or http://, then just use git clone and git update (which handle file:// just fine)

One problem plug has, and which I don't think is being addressed at all, is distinguishing user@host:path/to remotes (git+ssh). These don't look like scheme://.... You're currently using git* in the case statement, which covers both too much and too little. But that's a separate problem.

andreyorst commented 3 years ago

then just use git clone and git update (which handle file:// just fine)

Ah, that explains it -- I didn't knew that git clone would handle file:// urls. Then yeah, supporting file:// style urls is a good idea.

One problem plug has, and which I don't think is being addressed at all, is distinguishing user@host:path/to remotes (git+ssh). These don't look like scheme://.... You're currently using git* in the case statement, which covers both too much and too little. But that's a separate problem.

Yes, but this is a separate issue.

mralusw commented 3 years ago

Ah OK. I wasn't asking for anything so special. Just run of the mill miscommunication I guess, sorry about that.

andreyorst commented 3 years ago

Just run of the mill miscommunication I guess, sorry about that.

Yeah, no problem :) I too hope that I was not too annoying or harsh