Activitywatch: Create installation methods for non-developers

[ErikBjare]

Right now you pretty much need to be a developer to start using ActivityWatch.

One easy improvement we could make is to create a bash one-liner that installs ActivityWatch (much like the one-liner used to install brew). In the future (when we leave beta) we'd likely have to distribute installers/packages.

Would require some kind of process management for aw-server and watchers.

Must do:

• [x] Linux: Build a portable .zip
• [x] macOS: Build a portable .zip
• [x] Windows: Create a portable .zip

May do (secondary goals):

• [ ] Make ActivityWatch start on login for all installation methods (when possible, have a checkbox for those who want to opt out). See #116.
• [ ] macOS: Build a macOS .app (in progress, but stalled: https://github.com/ActivityWatch/aw-qt/pull/28)
• [x] macOS: Create a homebrew formula. Done by @freayd, install using brew cask install activitywatch.
• [ ] Linux/Debian: Build a .deb (work in progress)
• [ ] Linux: Create an AppImage? (Wikipedia)
• [ ] Linux: Create a flatpak. See #476.
• [x] Arch Linux: Create a PKGBUILD and upload to AUR (done)
• [x] Windows: Create an installer using NSIS or WiX Inno Setup.
• [x] Windows: Create a Chocolatey package (done: https://github.com/chocolatey/chocolatey-package-requests/issues/552)

And finally:

• [x] Put installation instructions in README

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[johan-bjareholt]

PyInstaller has gotten much better and more stable the past 3 years and has windows, mac and linux support. I don't know how advanced Gitlab CI is, but if it supports generating artifacts and such we could probably make a job that generates an executable pretty easily.

[ErikBjare]

@johan-bjareholt Holy shit, managed to get aw-server bundled in less than 5 minutes on OS X. We should definitely investigate PyInstaller further. 🎉

Looks like GitLab CI supports artifacts. If we could use it then hooray. Building for OS X and Windows might still be an issue on a Linux host (which we'll probably use for GitLab CI), and will probably have to involve VMs. 😭

Anyway, automating building the packages is probably premature optimization. For now we could just do it by manually running a simple build script.

[johan-bjareholt]

The only bad thing is that it sometimes creates pretty huge binaries but that can be optimized.

I agree, let's just make build scripts for now and do automation later.

[ErikBjare]

I think the primary action on this issue would be to build a .deb, and then build a macOS .app. When Windows support is tested we should create a portable .zip and also a installer using NSIS.

Adding these actions as TODOs.

[ErikBjare]

I've been looking into snap packages. Looks promising and not too difficult. Definitely something to explore but might not be a priority.

[johan-bjareholt]

@ErikBjare Flatpak is also a alternative to snaps.

[ErikBjare]

Ah yes, so flatpak is closer to snap? My first impression was that it was more akin to AppImage but looks like I was wrong.

[ErikBjare]

Flatpak seems to have much better support across distros: https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/

I must say I'm leaning towards flatpak after some reading. AppImages are also nice (for its usecase, sudo-less portability) but doesn't make much sense with the almost microservice-like architecture of ActivityWatch, for portability people might as well use the PyInstaller zips.

[johan-bjareholt]

In terms of functionality and community (freedesktop vs canonical) I would prefer flatpak, but flatpak is currently not available in the official ubuntu and debian repositories so we might be forced to use snap until then.

If i remember correctly it might be in the debian testing repos and the next debian version will be late this summer i believe so it might be in ubuntu 17.10? But that's just a guess.

[ErikBjare]

@johan-bjareholt Perhaps a .deb is the best way forward for now. Most people who don't use a distro supporting debs don't mind writing a few commands in the terminal to get what they want anyway.

On a more personal level, I think a PKGBUILD would be nice (started working on it as you saw) but I think I'd need some input from a more seasoned packager. Might check if there are some people on an IRC somewhere that can review my work when I get there.

[johan-bjareholt]

I don't think that we should make a pkgbuild, that would mean that we should provide all of our other python dependencies via pacman. It would be easier to just make packages installable via pip directly from github with "sudo pip install git+git://github.com/activitywatch/aw-server.git#egg=aw-server" and then watchers with "sudo pip install git+git://github.com/activitywatch/aw-qt.git#egg=aw-qt" as a start for developers.

[ErikBjare]

Ah right, fair enough. I remember I had thought about that in the past, thanks for clarifying.

[ErikBjare]

@johan-bjareholt I don't think we need to provide all dependencies via pacman. We could opt to install all dependencies via pip if we wanted in the pkgbuild, perhaps even specify an isolated environment where all dependencies would end up using the --root option to pip install (not polluting other Python programs on the system).

One major argument for providing a PKGBUILD would be to enable easier updates by end-users. People rarely (if ever) update their pip-installed packages. But perhaps still not a priority.

[johan-bjareholt]

@ErikBjare Have never seen a PKGBUILD which actually incorporates this, but it sounds pretty clean.

[ErikBjare]

Since the zips are done, I'm downgrading this to low priority.

[johan-bjareholt]

I don't think we should do a PKGBUILD, I'd prefer if we simply fixed so we could install from pip via git (such as "pip install git+git://github.com/activitywatch/aw-server.git#egg=aw-server") and then fix our .app bundle. After that I'd say that the packaging is in a rather good shape.

[ErikBjare]

We could do a simple activitywatch-bin PKGBUILD that just unzips into /opt/activitywatch or something. But yeah, a install-from-source PKGBUILD would probably be too much work for too little gain at this point.

Installing using pip alone would be nice, but can't be installed from git since we'd need to pre-build the web UI and some other stuff (like aw-qt's PyQt resource build step). One approach would be to register the packages on PyPI and ship source bundles with the prebuildt stuff included, but the complexity of maintaining the packages on PyPI is something I'd rather be without. Perhaps it could be automated in the CI process though.

The .app bundle definitely needs fixing (but I'm not sure how).

[ErikBjare]

Just completed that activitywatch-bin PKGBUILD and uploaded to AUR. See PR https://github.com/ActivityWatch/activitywatch/pull/174.

[ErikBjare]

Just started working on a .deb package here: https://github.com/ActivityWatch/deb-activitywatch-bin

[0xdevalias]

It would be awesome if this was included in homebrew.

[ErikBjare]

@0xdevalias Indeed it would be! Hopefully someone makes it so.

[ErikBjare]

Getting it up on Chocolatey would make installation and updating easier on Windows, I submitted a request for packager here: https://github.com/chocolatey/chocolatey-package-requests/issues/552

[BrunoVernay]

In terms of functionality and community (freedesktop vs canonical) I would prefer flatpak, but flatpak is currently not available in the official ubuntu and debian repositories so we might be forced to use snap until then.

If i remember correctly it might be in the debian testing repos and the next debian version will be late this summer i believe so it might be in ubuntu 17.10? But that's just a guess.

Flatpak are available everywhere.

[freayd]

Hi everyone. The brew formula is now available. You can install it with:

brew cask install activitywatch

Creating a .app would be a nice next step for macOS.

[johan-bjareholt]

@freayd Thanks for submitting the brew formula!

Yes, we definitely need a .app bundle, we have pushed on that issue for a bit too long now and really makes the macOS experience sub-par. It is not trivial though as PyInstallers support for apps is not great and I find the documentation on how .app bundles work from Apple being quite bad for non-xcode projects.

[ErikBjare]

ActivityWatch is now available on Chocolatey! Although the version published is ancient (the last stable version: v0.7.1) it's a good first step.

[ErikBjare]

Just finished putting together a Windows installer (that also sets up autostart for you). Here's the PR: https://github.com/ActivityWatch/activitywatch/pull/303

Will be available in the next release.

[xylix]

Are there any plans to implement or is there an update script?

I personally have upgraded aw a couple times on MacOS just by overwriting the old activitywatch folder with the newer ones and leaving all data intact. Is there some undesirable side effect or is this the preferred update method as of now?

[ErikBjare]

@xylix That's the preferred method yes. You can wipe the entire installation folder if you'd like as well, all your data is stored elsewhere.

There's now an installer for Windows, but macOS has been lagging behind in terms of packaging (we still haven't gotten around to building the .app) and unless someone with a mac picks this up that's unlikely to change anytime soon.

[ErikBjare]

With https://github.com/ActivityWatch/deb-activitywatch-bin/pull/1 merged I think we can start building the .deb in CI and offer it as an installation method.

[Baltix]

@ErikBjare Please, make normal ActivityWatch deb packages and repository for Ubuntu and Debian systems, I can help you with this task, it's not hard, see https://wiki.debian.org/Packaging/Intro
The main task is to make correct Debian source package and only from this source package you can then build the Debian binary package which is what actually get installed.
The source package consists, in its simplest form, of two things:
The upstream tarball, renamed to follow a systematic pattern.
A debian directory, with any changes made to upstream source, plus all the files created for the Debian package.

If you wanna make useful and correct debian packages then we should create separate packages for activitywatch-server (and maybe one more for activitywatch-server-rust), activitywatch-watchers, activitywatch-systray-qt. Each package should start his service (aw-server, aw-watcher-afk, aw-watcher-window, etc) in user-session either by having .desktop file in /etc/xdg/autostart or with systemd, see https://wiki.archlinux.org/index.php/Systemd/User and https://www.freedesktop.org/software/systemd/man/systemd.special.html#graphical-session.target
systemd offers users the ability to manage services under the user's control with a per-user systemd instance, enabling users to start, stop, enable, and disable their own units. This is convenient for daemons and other services that are commonly run for a single user, such as mpd

Only activitywatch-systray-qt package should depend on QT libraries and this package could depend or recommend activitywatch-server and activitywatch-watchers packages.

I can help you and take some tasks - please just create debian/control and debian/rules according to https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.pdf#Outline0.2.3.15 (you can use dh-make command for this) for each package (activitywatch-server, activitywatch-watchers, activitywatch-systray-qt) or one debian/control and debian/rules file for all packages if you will always distribute all activitywatch components sources in one archive.
I can do all other taks - compile and test deb packages, fix packaging issues, create PPA repository and write automated packaging building recipe from git, see for example
https://code.launchpad.net/~gnome-shell-extensions/+recipe/gnome-shell-extensions-enhancements and https://help.launchpad.net/Packaging/SourceBuilds

[ErikBjare]

@Baltix Your comment is mostly just duplicating what you already said in https://github.com/ActivityWatch/deb-activitywatch-bin/pull/1#issuecomment-629635402.

Each package should start his service in user-session with systemd

As I said in https://github.com/ActivityWatch/deb-activitywatch-bin/pull/1#issuecomment-629674772: We can't run the watchers as systemd services (at least not reliably), as they rely on an X session (and graphical-session doesn't work reliably on all distros, yet: https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg).

We welcome work to improve things, but we (the maintainers) do not prioritize working on the deb to get it up to Debian standards, since the issues are so many. I've created an issue with the past discussion we've had with @thomasgoirand here: https://github.com/ActivityWatch/deb-activitywatch-bin/issues/2