System package dependencies

[sagebind]

Now that we have package dependencies, we should add a feature to check for system dependencies as well for packages. For example, the weather plugin depends on the shark plugin, but it also depends on jq being installed. I propose enhancing the bundle file to iterate over available requirements as well, which would be verified by using the available function.

Package bundle files could now look like this:

available jq
package shark

If one or more available dependencies are not satisfied, the package should not be installed and the missing dependencies should be listed. We shouldn't try to install them ourselves.

We'll have to go through the whole file first to test the available lines first, since we shouldn't install any dependent OMF packages either if the dependencies aren't satisfied.

Thoughts?

[derekstavis]

👍 I like the idea! It's awesome! Better than implementing hand check over init.fish

[sagebind]

Here's a proof-of-concept that I have working: https://github.com/coderstephen/oh-my-fish/tree/feature/available-dependencies

[oranja]

Haven't tested it but it looks good at first glance.

Say, does available really work with a URL?
I have shark installed. available shark returns 0, but available (cat db/pkg/shark) returns 1.
Does it matter if I installed it from OMF's db or an external URL?
Anyway, I don't think it should be possible to specify a package by a full URL. Just a name and optionally a minimal version number. Not that versions are fun... It sucks when two packages want two different versions of the same dependency. 😖

[sagebind]

@oranja No, and it isn't meant to. We already have a package directive to depend on actual packages (which also works with external URLs). available is meant for system dependencies that we actually are unable to install ourselves. For example, if a package uses OpenSSL commands, it should have

available openssl

in its bundle file. OMF can't install OpenSSL, but we can at least warn the user that OpenSSL should be installed first before the package will work.

[bpinto]

Hey @CoderStephen

I think It might be better to add support for this inside a package.json-similar way. What do you think?

We could start a discussion around this configuration file.

[derekstavis]

I think It might be better to add support for this inside a package.json-similar way. What do you think?

Yes. I agree with package.json. What comes to my mind is something like this:

$ cat package
name: balias
type: theme
description: a description override (default is from github repo)

Dependencies are already handled in bundle file.

[bpinto]

I'm not sure if we should keep both bundle and package file. Shouldn't we merge them?

[oranja]

I also don't see any reason to keep more than one file for package metadata.

[derekstavis]

Ok, so what about this:

pkg/balias/package (No dependencies at all)

name: balias
type: package
description: a description override (default is from github repo)

pkg/nvm/package (OMF package dependencies)

name: nvm
type: package
description: a description override (default is from github repo)
dependencies: foreign-env

pkg/weather/package (OMF and command dependencies)

name: weather
type: package
description: a description override (default is from github repo)
dependencies: shark
command-dependencies: jq

theme/default/package (Themes with dependencies)

name: default
type: theme
description: a description override (default is from github repo)
dependencies: vcs technicolor

[oranja]

👍 👍
I find it satisfying, although maybe system-dependencies is a more suitable field name than command-dependencies?

[derekstavis]

I have the following understanding

• command-dependencies: Binaries found in path, can be called by command
• system-dependencies: Packages installed on system

And I also think about

• builtin-dependencies: Builtin commands, can be found by builtin, like HEAD's string

In this understanding, I don't thing we need system-dependencies.

[bpinto]

Is there any benefit on us supporting command dependencies? Not having it doesn't seem like a problem to be handled by the package dependency.

It seems to me that we only need to care at a metadata level about other plugin dependencies. And each plugin handles their dependency however the like to.

When I am using bundler to install gems, the only thing it handles for me is the dependent gems installation and nothing else.

[oranja]

A dev/maintainer should be aware and should notify others if a package requires special tools.
Letting a user install the rvm plugin when rvm itself is not installed, without any kind of warning, gives a false sense of success. If the package manager can tell that things are going to break, why not tell the user?

I am still going back and forth trying to convince myself if omf should encourage packages to specify different kinds of dependencies separately, or leave it as an option to when it's really needed (like rvm plugin requiring rvm to be installed). This way it leaves an option for a fish wrapper to take precedence over a system dependency (say, prefer grc's colorful ls -l over the bare ls -l).

Also, I'm not familiar with what is "HEAD's string"? If it is a Fish builtin, doesn't anyone who uses Fish have the same builtins? Maybe if it's a builtin which was introduced or changed drastically in a specific version, it should be possible to specify a minimum Fish version number.

[bpinto]

A dev/maintainer should be aware and should notify others if a package requires special tools.
Letting a user install the rvm plugin when rvm itself is not installed, without any kind of warning, gives a false sense of success. If the package manager can tell that things are going to break, why not tell the user?

We end up with a extremely complex framework. If you install rvm plugin and don't have rvm installed. The rvm plugin should handle it.

Its easier to think if the plugin was for ruby and any ruby manager could be used so it would automatically fallback to rbenv/chruby.

[bpinto]

Regarding built-in dependencies I don't think we should support it either. Basically they come with fish versions, we either support a specific version of fish or we don't. Same could be applied to plugins, though this fish version dependency for plugins could come in the future if ever necessary.

[sagebind]

We end up with a extremely complex framework. If you install rvm plugin and don't have rvm installed. The rvm plugin should handle it.

Perhaps we should add an install trigger mechanism then for plugins? Let's say plugin X depends on rvm. Installing X would trigger the installation of the rvm plugin. But if rvm isn't installed, the plugin should reject its own installation in its installation trigger, which in turn should reject installation of plugin X since its dependencies cannot be satisfied.

[oranja]

It kind of bugs me that eventually these plugins will have to "reinvent" the same procedure over and over again, when it can be centralized in omf's package management, but the final score says "go lean!". So I agree with @CoderStephen's suggested flow.

[bpinto]

I was talking to @derekstavis and we came up with the same idea with a "install" event, similar to "uninstall" and "init".

However, as you have expressed it might be an easy win to support basic dependencies (checked using the available function") on the metadata.

[derekstavis]

Yeah. Let's keep the idea of a centralised system for checking command availability. It doesn't cost too much on framework complexity and give a DRY treatment to packages.

[ghost]

@CoderStephen : there are multiple ways to install rvm though. I wouldn't want it to attempt to install rvm via say yum, when I prefer the version from source.

[ghost]

composer calls these kinds of dependencies platform-dependencies and has a flag to disable resolution of platform dependencies in case you plan on installing it after the fact or isn't needed on the production server (a dev env dep). Obviously the 2nd use case isn't that import antto us, but the first is. It's especially important if you install your stuff from a dotfiles repo before you might have the requisite packages installed.

[oranja]

@jrobeson I think @CoderStephen only meant that OMF plugins would be installed automatically. For platform-dependencies (I think it's a good name too), either the plugin or OMF should check for availability, but not auto-install. Adding a helpful tip on how to install is as far as I would go for platform-deps.
Adding an --ignore-dependencies X,Y,Z install option sounds like a wise move anyway, but maybe it's better to get something more basic working first and put extra flags in a later iteration.

[sagebind]

Correct. It isn't up to OMF to install platform packages for you, but to prevent redundant code in every plugin, OMF should warn and/or prevent installation of a plugin that depends on a platform package to be installed.

[sagebind]

This is now better solved via the new hooks system introduced by #286 -- packages can simply check for environment and system expectations it may have in an install hook.