Improve omf install to permit installing local packages from anywhere

[sethamclean]

I've generated a new theme skeleton and am looking for a way to install it. Installing using the theme name or setting the theme using the theme name fails with:

fatal: repository <name> does not exist

[oranja]

Hi @sethamclean,

Currently there is no mechanism for local installation through omf.

a) You can fake it by putting your theme folder directly under $OMF_PATH/themes/ and calling omf theme <yourtheme> to test it.

b) Sooner or later you might want to make the theme public. Most people go straight to github for that. If you upload your code to a repository named omf-theme-yourtheme or just theme-yourtheme, omf will be able to install that theme from github when you specify the repository's URL (e.g.: omf install https://github.com/sethamclean/omf-theme-yourtheme)

* Technically git accepts local paths as repository URLs, but omf often expects the format used for remote repositories to figure out what it is installing, so I fear specifying a local URL for omf install won't work.

Perhaps searching old issues would have floated some explanations, but I have to agree with you that this kind of thing belong in the documentation and we know that the documentation is lacking. We can use any help people can offer. Spotting the gaps is a good first step, but if you or anyone else have some time to add a few paragraphs it would be even better.

[sethamclean]

@oranja,

I'd be happy to put together a pull request with some updated documentation.

Would there be any interest in a pull request that adds the location themes/plugins are templated into to the search path?

[oranja]

:+1: for the first.

Not sure I follow you on the second though... :/ The search path for which component/command? And what locations exactly?

[logc]

Just had the same problem. Let me give a 👍 to add documentation, and suggest to remove these output lines when scaffolding a new theme:

Theme not installed!
Install it using omf install whatever

They are just misleading, don't you think?

[sagebind]

@logc Not quite. It looks like omf new for some reason calls omf theme <theme> on the newly scaffolded theme expecting it to work. The last two lines are the output of omf theme telling you that whatever is not installed and you can probably install it using omf install whatever. It does not know that it is a local package.

I think we need to rewrite omf new and not just change the documentation.

[mgoodness]

It looks like omf new for some reason calls omf theme on the newly scaffolded theme expecting it to work.

Couldn't a theme be sourced from its scaffolded location in $OMF_CONFIG rather than having to be copied/symlinked/installed to $OMF_PATH? I don't have to do anything special when developing a plugin, just omf new package <name> and edit/reload/test away. The difference in workflows is just different enough to be annoying 🤓

[sagebind]

@mgoodness I think the best way to solve this would be to allow users to "install" a theme from anywhere they like, and to do so automatically when creating one via omf new.

• Providing two or more search paths for installed packages will increase startup time, and also force us to have some sort of resolution strategy. What happens if you have a package called "foo" in $OMF_PATH and in $OMF_CONFIG? We would have to choose just one, otherwise that would be a recipe for disaster.
• Using symlinks offers greater flexibility to where users want to develop or install packages. For example, you could execute omf install ~/dev/my-fish-package and a symlink would be created automatically. This step could easily be done for you when executing omf new.

[sagebind]

Also relevant: #401 #432