Can I download the entire package just once?

[auwsom]

So far I've setup Mycroft about 20 times trying different ways, VBox, Virtmgr, Docker mycroft, ubuntu, minideb.. etc.

All this is burning up my bandwidth and seems really unnecessary as they are all accessing the same files.

Can I just download the entire package just once instead of having dev_mycroft download all the packages everytime? I'm using the same ubuntu or debian hosts everytime. Would a list of packages for apt help? The at least I could move them from /var/cache/apt/archives. Or could they be put into a reusable deb file? Or how about an AppImage?

[el-tocino]

Two things...

• why so many different ways?
• if they're installed in your system already, then you can look up how to do a virtual env using the system packages and hack that into the dev setup script in order to utilize those packages.

[auwsom]

Thanks @el-tocino for the quick response.

• Because as my other issue says I tried to use the Docker image last week and I had errors when I would to expect a container already setup to just work: https://github.com/MycroftAI/mycroft-core/issues/3037
• So took a while to setup my new VM using an Ubuntu image that needs no install, but that took a while because using cloud-init locally has a ton of gotchas. I got those working after going back and forth between Virtmanager and Virtualbox using each of their strengths. Finally got the audio issues worked out in Vbox as a positive sanity control.
• But I want to use a container because I want to send commands to the command line on my own machine. So I went back to my original errors I had with the prefab Mycroft container, see link above, and then started installing on either minideb or ubuntu, whichever is the smallest that has the easiest setup.
• Plus I had a bunch of installation and setup trials last year when I went through a similar process, but then have created new partitions and OSes since then on a new machine.
• Good idea about copying python packages from the venv (I dont have mycroft on my main system because I tinker to much when troubleshooting and need to keep it stable).. I'm just used to downloading deb files or Appimages (or Snaps or Flatpaks) for packages I expect to be installing in different environments. A big advantage to those or getting the Docker container to 'just work' will be to spare users the unnecessary setup hassle, and get on to making mycroft better.

[krisgesling]

Hey auwsom - if you're looking for a nice docker image for general usage checkout this one built by a community member:
https://github.com/smartgic/docker-mycroft

The official docker image is very bare bones - more of a template to build from and it's what we use in our CI processes.

[auwsom]

@krisgesling Thanks. That project is designed with a separate microservice for about 8 parts of Mycroft. After a week of plugging away at it, I've finally got a docker container working. I will upload it to DockerHub and also provide a script of the basic commands to convert the main docker-mycroft container to work (see issue #74 below). The main challenge is, as I mentioned in my troubleshooting issue below, is that pulseaudio is designed to be run as a user.

That should solve a lot of other user's pain if they can download a working docker image. The container ends up being about 5GB with Mimic. I'll try to trim it down. If you guys have interest in having an AppImage built that people could just download and run with one click on their Linux machines, let me know. There is a way to have them run on Windows as well.

MycroftAI/docker-mycroft#74

[krisgesling]

Hey - thanks for writing up all your learnings in that linked issue.

Longer term we're interested in other packaging formats like AppImage and Flatpak however it's not a priority for us at the moment. The user experience for desktop is not there yet, and our focus is squarely on the Mark II.

We adopted a community built Snap a while ago but it still requires a bunch of work to get it into a usable state. The biggest frustration is when packages like this get created once - seem like they are the official version, and then provide a terrible experience. So if you're keen to work on an AppImage we'd want to make sure it was fully integrated with our other build processes and getting updated regularly. But again - I want to stress that a desktop install is not a priority for us at the moment so we can't promise resources to support the project.

[auwsom]

@krisgesling, Great thanks for the info. I finally arrived at the crux of the problem with the official docker image.. and it turns out to be quite simple. The docker run.. command in the documentation simply needs to be run as a non-root user. Could you consider adding that to the support docs? Adding that requirement, with some italics or bolding, and putting a "sudo" in front of the docker command would make that much more clear. Pulseaudio will not work without lots of caveats as root, and Docker is most often run as root, so there is a natural conflict in the setup.

I see some "Known issues" on the Snap Mycroft page (https://snapcraft.io/mycroft), but why is it considered not a usable state?

I was working on the Docker image because I can test things and easily reset the image. Now it is working, there's less attraction for me to an AppImage, however, I still think it would help increase Mycroft adoption in general.. especially if it can be run with one click, no setup. PortableApps are popular on Windows, AppImages look like they can work on WSL, and there is a similar project to WSL started for Mac called Noah.

I'm curious, how is the desktop considered different from the Mark II? The mycroft-gui looks similar to a Cortana desktop interface, from the one image I found. Could the Mark II gui function as a desktop gui? If not, what are the major differences in design goals? Thanks

PS, the Dev Sync really helped me see what you guys are working on. I'll leave a comment over there with some feedback.
https://community.mycroft.ai/t/mycroft-dev-sync-2021-11-29/11562/5?u=auwsom

[forslund]

Closing Issue since we're archiving the repo