On Sat, Oct 24, 2015 at 7:10 PM Ted Gould <ted@ubuntu.com> wrote:
So, there is a lot of different things here. This e-mail is going to be long, sorry about that. tl;dr, it's complicated, if you care you should actually read it :-)
The Ubuntu archives is a repository of Debian packages, to get a package in there you need to follow all the licensing requirements of the Ubuntu community and get a developer of appropriate privileges to approve the package and sponsor it into the repository. A Debian package can depend and use any other Debian package in the archive, so using Python (any version) is not a problem there. For something to be in the main repository it can only depend on packages in main, but Python again is not an issue. To create a service with a Debian package you need to install a Systemd unit file that describes the service and it can launch at various times depending on the configuration in the file. Any deb package can do this.
For the Ubuntu Phone an image is created from a bunch of debian packages from the Ubuntu archive. The list of packages is determined by Canonical and the OEMs that are shipping the phones. That image is then installed read-only onto a phone, so adding additional debs is impossible without invalidating it's ability to upgrade to new images (really only for developers). To extend the phone Click packages can be used, but Click packages were designed primarily for applications so they don't have any features like services as part of their specification. There is no way to build a Click that would install a service on the Ubuntu Phone today. Also, there has been a significant effort to remove long-running Python tasks from the phone image because of the memory costs associated with them, as there is significant memory pressures on those devices today. That being said, if Canonical and and OEM really wanted to change that package listing, there's no technical reason it couldn't include any debian package in the archive.
The future of the Ubuntu Phone is having it be built on Snappy, which changes things significantly. Snappy realized the goodness and goals of Click and extended them to be more generic for building any system service. So a snap can have a service associated with it that can be run at the system level similar to how you've described. Snaps can be built from the Ubuntu archive or from other repositories (a popular one is PyPi) depending on the needs of the developer building the snap. It can include things like the Python version that is needed or anything else, the intention is that it is self contained with everything it needs.
Now, looking into the crystal ball a bit (not decided, but I'm guessing here), it seems unlikely that we will present to the user of an Ubuntu Phone the ability to install all the snaps that are in the store. There will be things that will be cloud and server based that most users would not want on a phone. It is highly likely that a line that will be drawn there is whether it installs a service. So then, for a standard user, there will not be a way to install things like an Apache Webserver on their phone easily. I imagine there'll be also a way to, with something like adb, install any snap that is in the store. So if you're someone who really needs a webserver on their phone, go with it. So that means that for the majority of devices, to have something that is service based, you'd need to be included in the Gadget snap which configures which other snaps are on the device. This will largely be determined by the OEM shipping the device. I imagine Canonical will require shipping the Unity snap as part of the requirement to use the Ubuntu Phone trademarks, but that is speculation.
So, my advice, you've probably already built a snap for Mycroft. That's great, you should do that. It's probably the best way to get onto devices like the phone. Your next step would be to try to get OEMs interested in including that on their device. One great way would be to make it easy for hobbyists to get it on their devices, and putting a snap in the store is a good step in that direction.
HTH,
Ted--
On Fri, 2015-10-23 at 16:28 -0300, Jonathan D'Orleans wrote:Thank you all for the replies, that's really important for us.
For integration I mean to be able to run a background process just after Ubuntu is started and to launch an UI as soon as someone start interacting with Mycroft. We could imagine the follwing steps:1. Turn on your Ubuntu device and login2. Say, for instance: "Hey Mycroft, what's my schedule for today?"3. Mycroft speaks it out and at the same time Mycroft UI is launched showing you the schedule.
So, if I well understood we can use Upstart to autostart Mycroft as soon as Ubuntu is started. We also could develop a Scope or QML App to be the Mycroft UI.
Supposing we would communicate between Mycroft background process and a QML UI we could use PyOtherSide. However, I'm not sure how it'd work for a Scope UI instead (Scopes are developed in C++ or GO, right?).
I'm a little bit confused about Python support. That's a crucial point for us to know.
By default Ubuntu won't have any Python dependencies. Hence, in order to solve those we would ship Mycroft in a .deb and solve all needed dependencies.
Will only Python 3 be available or Python 2.x would be installable as well ?
Supposing we use Snappy, if I well understood, Mycroft would be shipped in a container and then its environment would be isolated from everything outside that. Then, inside Mycroft container we could solve all dependencies including Python etc. However, I didn't understand what you mean by: "The difficult part here is that the interfaces may not have Python libraries to access them".
Do you mean that applications from another Snappy container could not be able to communicate with Mycroft?
Finally, are my assumptions correct? Is there any point you could elaborate more if needed?
Again, we are really grateful for your support,
On 23 October 2015 at 13:05, Ted Gould <ted@ubuntu.com> wrote:On Fri, 2015-10-23 at 15:05 +0200, Michał Sawicz wrote:> As Mycroft client is in Python it'd be important for us to run it > natively in mobiles. > 2. Anyone knows if Python will be natively supported for Ubuntu mobiles > versions? Are there any restrictions or particularities for that to > happen? AFAICT there's no plans to support Python as a developer language for the platform, mostly because of resource considerations. Python (only version 3), however, is available on the device today, so if Mycroft became part of the platform, shipped on the devices, it'd need to be packaged as a .deb with appropriate dependencies. Note that, without knowing how you want to integrate, I can't comment on whether it's even a possibility for the products.
As we move to a Snappy based system apps will be able to include the interpreter of their choice. So if, for instance the Mycroft developers wanted to include Python3 they could and Snapcraft makes that pretty easy. The difficult part here is that the interfaces may not have Python libraries to access them, which is where choosing a different language could become tricky.
It is important to note that in a Snappy world the base system doesn't have an accessible Python3 interpreter. And I don't believe anything that would be shipped as part of a Unity8 framework would ship it.
Ted
--Jonathan D'Orleans-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
