activitywatch
activitywatch copied to clipboard
ActivityWatch
Create installation methods for non-developers
~~Right now you pretty much need to be a developer to start using ActivityWatch.~~ (not anymore!)
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.~~ (we now have aw-qt)
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.
- [x] macOS: Build a macOS
.app(done, but issues remain) - [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.
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.
@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.
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.
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.
I've been looking into snap packages. Looks promising and not too difficult. Definitely something to explore but might not be a priority.
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.
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.
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.
@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.
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.
Ah right, fair enough. I remember I had thought about that in the past, thanks for clarifying.
@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.
@ErikBjare Have never seen a PKGBUILD which actually incorporates this, but it sounds pretty clean.
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.
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).
Just completed that activitywatch-bin PKGBUILD and uploaded to AUR. See PR https://github.com/ActivityWatch/activitywatch/pull/174.
Just started working on a .deb package here: https://github.com/ActivityWatch/deb-activitywatch-bin
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
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.
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.
@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.
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.
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.
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?
@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.
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.