S On Sat, Oct 24, 2015 at 7:10 PM Ted Gould <[email protected]> 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 login > > 2. 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 <[email protected]> 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 [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > ubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
