project dependency

[nickthecook]

Sometimes one repo needs a service defined in another repo to be running in order to run itself. E.g. there is an app and a monitoring system; the app needs to send data to the monitoring system (or, at least, a developer should be able to test this).

With a dependency like this defined in the app's ops.yml:

dependencies:
  project:
    - ~/src/monitoring

ops up should try to start the service in the given project directory (monitoring). The monitoring project must have an ops.yml file as well, that supports the following actions:

• start
• stop
• status
• (optionally) restart

Because these are not ops builtins, ops will need to be able to provide a helpful message in the case that the other project has not defined these actions.

Some consideration must be given to how to invoke these other actions, and whether they must, by themselves, run in the background. E.g. perhaps ops start runs a server in the foreground, so that a developer can see the log output.

• Should ops run start in a background process, or dictate that the ops start action must start a service and return?
• Should ops use an action other than start, so that the action used to start projects does not conflict with a commonly-used action name?
• Should ops use a builtin to handle this, e.g. ops service start that will run ops start in the background?
• Should ops make the logs of backgrounded services available to developers via commands like ops logs, or rely on the app to write its own logs?

[ErikHumphrey]

Since ops up/dependencies handle both installing dependencies and starting services, without reading the documentation,, it would be difficult to tell that ops up would run ops start (or similar) in monitoring rather than ops up. With a custom dependency this isn't so ambiguous, but my first impression would definitely be that project would only try to install something without running any services (unless running services in the background was clearly part of the application's install). Though the fact that the dependency project has to have an ops.yml will probably force the user to read the documentation anyway, it might be a good idea to make it readable for people that didn't write the config. Maybe there is a simple way (new config section) to separate installed dependencies from installed/run services, or a way to choose what ops command is run on the dependency. A new built-in might be another way of handling that.

I would expect there to be logs and output when initially running the service, but no output + control returned to the user when the service is up and running successfully, but I wouldn't expect ops to generate its own log files.

[nickthecook]

Since ops up/dependencies handle both installing dependencies and starting services, without reading the documentation,, it would be difficult to tell that ops up would run ops start (or similar) in monitoring rather than ops up.

The docker dependency starts a service in a container, and the potential future dependency service would start and stop a system service as a dependency. So ops up will not just install things, but will also run things, if it's a type of dependency that requires that. I don't think the word "dependency" implies that the thing on which your project depends is that some software is installed.

But if I say "project A depends on project B", do you read that as:

• running project A requires project B's dependencies to be installed

or

• running project A requires project B to be running

I suppose "depending" on a "project" could mean a dependency as in using a library or a dependency as in integrating with a service. Is there a word other than project that would communicate the latter more clearly? I'd rather not use service as I think that means something else in this context.

Though the fact that the dependency project has to have an ops.yml will probably force the user to read the documentation anyway

It is an active decision on a user's part to use the project dependency, so the user would need to be aware that the target of that dependency needs to implement certain actions in a certain way. ops might also be able to return a decent message in the case that an expected action in the target of a project dependency was not implemented; e.g. "The project '~/src/monitoring' does not implement the action 'start', which is required to use it as a 'project' dependency".

Maybe there is a simple way (new config section) to separate installed dependencies from installed/run services, or a way to choose what ops command is run on the dependency. A new built-in might be another way of handling that.

So instead of calling actions, there could be a builtin that was run in the other project, like:

ops service start

which might wrap the project's normal start action in some backgrounding logic? That way you could implement start the natural way - starting an app in the foregound - but when used as a dependency for another project, your app would be put in the background.

I would expect there to be logs and output when initially running the service, but no output + control returned to the user when the service is up and running successfully, but I wouldn't expect ops to generate its own log files.

It makes sense for the process to be started in the background, as long as the service started successfully, but otherwise you'd see error output on your terminal.

[ErikHumphrey]

But if I say "project A depends on project B", do you read that as: [...]

Both; "Project A depends on Project B" reads like Project A needs all of Project B's dependency's and needs Project B to be running sometimes.

---

Re: project not clearly implying what it does

To make the functionality of the dependency unambiguous, you could call it start or started. Or because the project dependency isn't a real system service, you could call it background or process if those fit the same definition as a service.

Alternatively, the service dependency could be renamed daemon. Although "service" is still somewhat common terminology with Unix systems, daemon would actually be less ambiguous. Not really universal to Windows, but Windows isn't a common host for ops. This would allow for the project dependency to be called service, i.e., what a server provides.

Edit: start would cause confusion if ops start is used, though.

[nickthecook]

Both; "Project A depends on Project B" reads like Project A needs all of Project B's dependency's and needs Project B to be running sometimes.

I thought the same, which is why I thought it would communicate to the user that the projects listed there would be started, in addition to having their dependencies installed. Hence, I think that it would be somewhat natural for ops to run ops start or something in monitoring when running ops up in a dir with a project dependency for monitoring.

To me, daemon means something that runs in the background, but isn't necessarily installed in your system as a service, whereas service is the term for a daemon that is installed in your system and can be managed with a service command (like brew service or just service in linux). Conversely, something that is meant to run in the background but cannot be managed via brew service or service is not a service, but just a daemon.