Mycroft-core: Simplify CLI commands for stopping and starting Mycroft services

Created on 15 Sep 2017 · 8Comments · Source: MycroftAI/mycroft-core

_Origin: This Issue is being raised based on a conversation b/w @kathyreid and @penrods and is aimed at making stopping and starting Mycroft services more intuitive_

User stories

As a developer or command line user of Mycroft, I want the process for stopping and starting Mycroft services to be intuitive, so that I can focus on extending the platform instead of on basic usage.

As a core maintainer of Mycroft, I want the process for stopping and starting Mycroft services to be intuitive so that the volume of 'Getting Started' questions is reduced, allowing me to focus my time on extending functionality and debugging advanced issues

As a developer, CLI user or core maintainer of Mycroft, I want starting and stopping services to be intuitive and parameterised so that future development can easily trigger service stops, starts and restarts.

Acceptance criteria

Starting, stopping and restarting Mycroft services follows a standard, intuitive syntax. For example this could mirror the syntax used by systemctl on Ubuntu - along the lines of:

$ mycroft [action] [subservice] [parameter]

eg.

$ mycroft start all
$ mycroft stop all
$ mycroft restart all

$ mycroft start voice
$ mycroft start all --quiet

This approach should be socialised with, and input sought from, the Mycroft Developer community
The syntax should be clearly documented both in the README.md for the mycroft-core repo, and also in docs.mycroft.ai (this will be @kathyreid's job)

medium Enhancement - proposed help wanted

Source

KathyReid

Most helpful comment

I'd like to propose we do this with couple of very findable scripts. Namely:
$ ./mycroft-start.sh
$ ./mycroft-stop.sh

When just browsing the filesystem, these will jump out to a novice -- "oh, that's how you start it!"

There is no need for restart, "start" should stop anything that is already running (we can't allow duplicate services to be running). No services have parameters so we don't need that either.

penrods on 15 Sep 2017

👍2

All 8 comments

I'd like to propose we do this with couple of very findable scripts. Namely:
$ ./mycroft-start.sh
$ ./mycroft-stop.sh

When just browsing the filesystem, these will jump out to a novice -- "oh, that's how you start it!"

There is no need for restart, "start" should stop anything that is already running (we can't allow duplicate services to be running). No services have parameters so we don't need that either.

penrods on 15 Sep 2017

👍2

This makes a lot of sense - apologies my initial take on this wasn't quite right.

KathyReid on 16 Sep 2017

I propose a simple UI. I was (am) a Windows .NET, WPF, etc programmer so my initial response is to make a UI. How about something simple that shows the status of the various states and then has a place to enter text and shows output text. Also can start, stop, whatever. This would not work on the picroft but what I could do is have a backend that could have command line parameters that the UI would read. I know all you Linux types love command lines but for the artists, designers etc. out there they would appreciate a UI. Python has a bunch of UI frameworks and if we just started small and did the easy things it could progress and eventually be all crazy.. How about it? Want me to draft a prototype? I have been looking for something to start with. This could be fun.

highjinx411 on 18 Sep 2017

Does mycroft want to forcibly stop any service it finds matching whatever it's trying to start? Would this be problematic with any of the services?

Also I'd vote for the name changes to drop start.sh (fold into mycroft.sh, for all your granular needs?), adding start-mycroft.sh, and stop-mycroft.sh.

el-tocino on 20 Sep 2017

@highjinx411 I'm guessing you were talking with me about this on Mattermost the other day. A GUI is a good idea, but it won't be part of mycroft-core, which is intended to be cross-platform and (accordingly) as independent of things like window management systems as possible. A GUI like you are proposing would be an enclosure, much like "enclosure-picroft", e.g. "enclosure-windows".

If you can come up with a truly cross-platform GUI, I'd be interested in seeing it, too!

P.S. I'm an old Windows guy myself -- I did most of the GUI development for AutoSketch 4 to AutoSketch 10 back in the day. I love a good user interface!

penrods on 22 Sep 2017

A cross platform GUI could be possible but it would probably be limited as it would give up any benefits you would get from making it platform dependent. So you might lose Windows specific calls for example that could be a benefit if the app was on Windows. I agree that it should be part of the enclosure to make sure it is as rich as possible. Even developing "cross" platform apps with Xamarin for mobile phones for example has parts in it which are platform dependent and in the end build a specific executable for each OS anyways. The only thing that should be available to all the GUI's is something in the core that exposes start, stop, get status etc.. So all the GUI's can call the same methods regardless of what platform the core is installed on.. Actually even just saying that now I am not sure as Linux does well with bash scripts but windows could do well via some other method. So the question is. Is the GUI going to look at the mycroft core instance for it's platform? The windows GUI only looks at windows core and the Linux GUI only looks at Linux core? Or could it be the Windows gui could have an IP as an input and accesses core wherever that IP is installed at regardless of OS?

highjinx411 on 22 Sep 2017

I believe PR #1107 should do the trick. Whatcha think, @KathyReid, close this one?

penrods on 28 Sep 2017

Agreed @penrods, closing this issue.

KathyReid on 8 Dec 2017

Was this page helpful?

0 / 5 - 0 ratings