{"action":"created","issue":{"url":"https://api.github.com/repos/foosel/OctoPrint/issues/1922","repository_url":"https://api.github.com/repos/foosel/OctoPrint","labels_url":"https://api.github.com/repos/foosel/OctoPrint/issues/1922/labels{/name}","comments_url":"https://api.github.com/repos/foosel/OctoPrint/issues/1922/comments","events_url":"https://api.github.com/repos/foosel/OctoPrint/issues/1922/events","html_url":"https://github.com/foosel/OctoPrint/issues/1922","id":229436310,"number":1922,"title":"[Brainstorming] Make OctoPrint distro packages","user":{"login":"Depaulicious","id":1151321,"avatar_url":"https://avatars1.githubusercontent.com/u/1151321?v=3","gravatar_id":"","url":"https://api.github.com/users/Depaulicious","html_url":"https://github.com/Depaulicious","followers_url":"https://api.github.com/users/Depaulicious/followers","following_url":"https://api.github.com/users/Depaulicious/following{/other_user}","gists_url":"https://api.github.com/users/Depaulicious/gists{/gist_id}","starred_url":"https://api.github.com/users/Depaulicious/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Depaulicious/subscriptions","organizations_url":"https://api.github.com/users/Depaulicious/orgs","repos_url":"https://api.github.com/users/Depaulicious/repos","events_url":"https://api.github.com/users/Depaulicious/events{/privacy}","received_events_url":"https://api.github.com/users/Depaulicious/received_events","type":"User","site_admin":false},"labels":[{"id":117339329,"url":"https://api.github.com/repos/foosel/OctoPrint/labels/type:brainstorming","name":"type:brainstorming","color":"fbca04","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2017-05-17T17:46:29Z","updated_at":"2017-05-30T15:59:45Z","closed_at":null,"body":"A big thing that always left me unsatisfied about OctoPrint is the way it is placed in the filesystem. It's very Raspberry Pi centric, and by that I mean that it's usually acceptable to put things in `pi`'s home in Raspbian, then run them as `pi`, but that looks very unclean to me anywhere else.\r\n\r\nThis _issue_ is more evident if you want to autostart OctoPrint on boot. There are sysv startup scripts, etc., and what they do is simply start it as `pi`, with the path _hardcoded_ to `/home/pi/...`.\r\n\r\nI believe OctoPrint should be made more relocatable and, by default, placed in a system directory (`/usr/share`, `/opt`?), not only to make it \"more elegant\", but to better automate tasks such as setting up bootup scripts/units, supporting stuff like systemd's socket activation, and distributing it as distro packages.\r\n\r\n### About distro packages\r\nThough I really like the fact that OctoPrint is set up in a virtualenv, so that it doesn't mess up with the rest of the system, I feel like it's not the most convenient way to do it. I think OctoPrint could be modified a bit to support a distro package installation, in addition to the current virtualenv setup.\r\n\r\nI know this is not a trivial task, which is why I'm writing here; I hope this will start a useful discussion.\r\n\r\nI haven't thought very much about it, but this is a basic list of things that I think need to be done in order to implement this:\r\n\r\n- OctoPrint should be able to install itself as a system Python module (I think that's already feasible) and detect that, so that it won't try to update itself and let the distribution package manager handle this part.\r\n- It should also be able to install the plugins into some user-writable directory (`~/.local/share`?), so that 1) users can have their own independent OctoPrint daemon (don't really see the use case but why not :rofl:) and 2) it does not mess up with the system packages 3) It would be compatible with packaging systems like `snap`, which totally forbid the modification of the software image\r\n- It should be started by startup scripts as its own unprivileged system user (`octoprint`?), like how every other daemon does.\r\n- Startup scripts/units should be generated at \"build\" time, customized for the targeted packaging system\r\n\r\n### Possible use cases\r\n\r\nOther than seeing a nice `octoprint` package in popular distributions' repositories, the main reason why I think this is a thing to do is `snap` compatibility.\r\n\r\nSnap combines the trouble-safety of a virtualenv with the ease of use of a distribution package, allowing users to simply `snap install octoprint` and be ready to go. It will be quite a pain though, as it's very restrictive on what program has access to which component of the system, but I think the result will be worth it.\r\n\r\nI can already imagine a \"smart IoT printer\" for sale with OctoPrint preinstalled as a snap app on Ubuntu Core or similar, allowing users to simply reset the system to a known state with one button.\r\n\r\nLet me know what you think about this ;)"},"comment":{"url":"https://api.github.com/repos/foosel/OctoPrint/issues/comments/304925400","html_url":"https://github.com/foosel/OctoPrint/issues/1922#issuecomment-304925400","issue_url":"https://api.github.com/repos/foosel/OctoPrint/issues/1922","id":304925400,"user":{"login":"foosel","id":83657,"avatar_url":"https://avatars3.githubusercontent.com/u/83657?v=3","gravatar_id":"","url":"https://api.github.com/users/foosel","html_url":"https://github.com/foosel","followers_url":"https://api.github.com/users/foosel/followers","following_url":"https://api.github.com/users/foosel/following{/other_user}","gists_url":"https://api.github.com/users/foosel/gists{/gist_id}","starred_url":"https://api.github.com/users/foosel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/foosel/subscriptions","organizations_url":"https://api.github.com/users/foosel/orgs","repos_url":"https://api.github.com/users/foosel/repos","events_url":"https://api.github.com/users/foosel/events{/privacy}","received_events_url":"https://api.github.com/users/foosel/received_events","type":"User","site_admin":false},"created_at":"2017-05-30T15:59:45Z","updated_at":"2017-05-30T15:59:45Z","body":"> Of course none of these are actual issues to distribute packages from unofficial repositories, but I think it's better to do things correctly in an open and transparent way from the beginning.\r\n\r\nTo be honest, I would first and foremost try to target the creation of a `deb` file, THEN worry about the intricacies of individual distributions, especially ones that are as strict as Debian (which based on past discussions I had with Debian maintainers is somewhat of a nightmare to cater to). I'd rather be able to offer up packages on an unofficial repository than none at all."}}
{"actor":{"display_login":"foosel"}}