Installation with user/repo syntax

[fdeitylink]

Description

Allows installation from GitHub repositories with user/repo syntax. Shorthand for URL syntax, more or less, with GitHub as the forge.

Fixes #818

Environment report

Oh My Fish version:   7-35-g332ca07
OS type:              Linux
Fish version:         fish, version 3.1.2
Git version:          git version 2.25.1
Git core.autocrlf:    no
Checking for a sane environment...

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• New and existing tests pass locally with my changes

[bobthecow]

Should we refer to packages installed this way as user/repo? Otherwise we have potential collisions as multiple users might have the same repo name, and repo names might collide with package names from the registry.

Thinking about it, maybe a good approach would be to install these as @user/repo in the filesystem, while still allowing them to be referred to as either user/repo or repo as long as there is no ambiguity.

[fdeitylink]

That's a good point. I have to test if installing to $OMF_PATH/pkg/user/repo would break anything since packages are expected to be found in $OMF_PATH/pkg. Additionally, if we're going with that, I think we shouldn't use omf.packages.name to set a package name when installing via URL or user/repo syntax. In my opinion it creates a potentially confusing disparity between installation and uninstallation. Thoughts?

[bobthecow]

Oh, yeah. I was thinking that @user/repo would keep the ones installed via this mechanism from colliding, but I guess we have a similar problem with packages installed by URL.

[fdeitylink]

I'm thinking the installation subdirectory could map basically 1 to 1 with the installation "name".

• Install via name (i.e. something registered in packages-main): $OMF_PATH/pkg/name
• Install via name/repo: $OMF_PATH/pkg/name/repo
• Install via url: $OMF_PATH/pkg/url

This isn't wholly uncommon, prevents conflicts, and usually users shouldn't need to muck around in the pkg directory much anyway.

[scorphus]

The separation of plugins in namespaces to avoid collisions seems like a good idea, but I think it shouldn't prevent this PR to be merged, as the functionality is already there — and so is the collision. I'm merging this one and opening an issue for when we'd like to improve pkg installation and mitigate collisions.

[scorphus]

Many thanks, @fdeitylink! 🙌