Open nickthecook opened 4 years ago
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.
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:
or
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.
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.
project
not clearly implying what it doesTo 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.
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.
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
:ops up
should try to start the service in the given project directory (monitoring
). Themonitoring
project must have anops.yml
file as well, that supports the following actions: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.ops
runstart
in a background process, or dictate that theops start
action must start a service and return?ops
use an action other thanstart
, so that the action used to start projects does not conflict with a commonly-used action name?ops
use a builtin to handle this, e.g.ops service start
that will runops start
in the background?ops
make the logs of backgrounded services available to developers via commands likeops logs
, or rely on the app to write its own logs?