Replace aw-server-python with aw-server-rust

[johan-bjareholt]

To do:

• Blinking aw-server-rust integration tests on windows (both travis and appveyor)
• macos in travis now for some reason uses python2?
• Travis fails with exitcode 1 though "make package" returns 0?
• Need to verify packaged contents and test on all platforms

[ErikBjare]

Could you please avoid removing aw-server-python and keep both in the repo so that this PR can be merged even though we're not ready to completely move over to aw-server-rust?

Building the bundle with both for a release or two would also let users test it before we switch over.

[ErikBjare]

Also, apparently the Python 2.7 on macOS has to do with the aw-core (and maybe other) Makefile using pip instead of pip3.

[johan-bjareholt]

Could you please avoid removing aw-server-python and keep both in the repo so that this PR can be merged even though we're not ready to completely move over to aw-server-rust?

How do you expect that to work? aw-qt will start both automatically if it's packaged properly.

Building the bundle with both for a release or two would also let users test it before we switch over.

My idea was that it might be a better idea to just release "actual" beta versions.

[ErikBjare]

How do you expect that to work?

We'd simply make aw-qt not start aw-server-rust by default, or perhaps even better make it a configurable which one to use (until that is done, you can specify it by giving aw-qt the --autostart-modules parameter).

I want this for testing purposes regardless (especially because of #327). When we in the future want to exclude aw-server-python from builds, I suggest we do that with a CI build flag instead.

My idea was that it might be a better idea to just release "actual" beta versions.

I'd rather not honestly. If so I'd expect us to have a separate branch for it, and maintaining a separate release channel/branch is too much work with our submodule-based repo layout (if we had a monorepo that'd be a different story).

[ErikBjare]

aw-qt will start both automatically if it's packaged properly.

After re-adding aw-server-python and taking a look at aw-qt I realize that it would not for two reasons:

1. Expected/possible modules are actually hardcoded in aw-qt, I added aw-server-rust in the dev/poetry branch of aw-qt that I'll hopefully get merged soon. (done)
2. aw-qt takes its --autostart-modules argument which defaults to ['aw-server', 'aw-watcher-afk', 'aw-watcher-window'].

[ErikBjare]

Travis fails with exitcode 1 though "make package" returns 0?

Travis doesn't terminate on the first non-zero exitcode step in script, it will run all commands and if any exits with a non-zero code it will fail the build.

[ErikBjare]

CI should work now, apart from the failing aw-server-rust integration test.

[johan-bjareholt]

We'd simply make aw-qt not start aw-server-rust by default, or perhaps even better make it a configurable which one to use (until that is done, you can specify it by giving aw-qt the --autostart-modules parameter).

I want this for testing purposes regardless (especially because of #327). When we in the future want to exclude aw-server-python from builds, I suggest we do that with a CI build flag instead.

Fair enough

I'd rather not honestly. If so I'd expect us to have a separate branch for it, and maintaining a separate release channel/branch is too much work with our submodule-based repo layout (if we had a monorepo that'd be a different story).

If aw-server-rust was a WIP I'd agree, but all features are working and have done so for almost a year so there's only bug hunting and incompatibilities with watchers left to investigate.

Expected/possible modules are actually hardcoded in aw-qt, I added aw-server-rust in the dev/poetry branch of aw-qt that I'll hopefully get merged soon.

While the name of the git is "aw-server-rust" the name of the binary is now just "aw-server" since I split it up into modules, if we do it like this we need to manually rename the binary in the Makefile.

aw-qt takes its --autostart-modules argument which defaults to ['aw-server', 'aw-watcher-afk', 'aw-watcher-window'].

Oh, just realized that ActivityWatch/aw-qt#27 never got finished, didn't know.

Travis doesn't terminate on the first non-zero exitcode step in script, it will run all commands and if any exits with a non-zero code it will fail the build.

Huh, that's... interesting behavior to say the least. I'd expect it to do "set -e" by default but apparently not.

[ErikBjare]

if we do it like this we need to manually rename the binary in the Makefile.

I did, in 0aec062.

Huh, that's... interesting behavior to say the least. I'd expect it to do "set -e" by default but apparently not.

The idea is to let it run tests/linting/typechecking/whatever such that if more than one fails you can fix them all in one go.

[johan-bjareholt]

@ErikBjare I'm starting a windows VM now to try and fix the blinking test.

[ErikBjare]

@johan-bjareholt How did that blinking test go? Want me to take a look at it?

[johan-bjareholt]

@ErikBjare I fixed and merged it this weekend, works fine!

There's one thing failing in Travis in the aw-server-rust Repo and that's some Travis caching mechanism taking more that 10min on macOS (so that shouldn't impact this repo as it's specific to projects marked as rust which this isn't). Otherwise tests are reliable now as far as I know.

[johan-bjareholt]

Aw-qt errors for windows now and some strange network error for macOS

[ErikBjare]

The macOS network error is just a spurious error. I restarted the build.

Seems like the perl regex that's used as a workaround for a poetry issue with packing the .gitignore'd aw_qt/resource.py is failing on Windows. I can look into that, probably has to do with a perl version mismatch. I might just change it to use Python instead.

One other thing though, even though it is failing the build also seems to timing out. Is aw-server-rust correctly shut down in the integration tests?

[johan-bjareholt]

One other thing though, even though it is failing the build also seems to timing out. Is aw-server-rust correctly shut down in the integration tests?

Yes, aw-server is compiled into the aw-client-rust tests so they run as the same process. When the main thread shuts down (the test thread) the server itself shuts down with it. Not the cleanest way (as there is no way to cleanly shut down a rocket server apparently), but it does what it should.

Kind of odd as in appveyor it shuts down properly in 15-20min while travis times out after 50min, strange.

[johan-bjareholt]

It's something with the .travis.yml stdout timeout thing not shutting down properly probably

 - while sleep 9m; do echo "=====[ $SECONDS seconds still running ]====="; done &
 - make build
 - kill %1  # Killing background sleep loop

[johan-bjareholt]

Seems like the perl regex that's used as a workaround for a poetry issue with packing the .gitignore'd aw_qt/resource.py is failing on Windows. I can look into that, probably has to do with a perl version mismatch. I might just change it to use Python instead.

@ErikBjare Any progress on this?

[johan-bjareholt]

Maybe just replacing perl with sed would fix it?

[ErikBjare]

@johan-bjareholt Unfortunately sed has platform differences between macOS and Linux which makes it difficult to use in CI, which is why I switched to perl in the first place: https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux

Things seem to work in the master branch, so maybe merging it into this PR will fix it?

It's something with the .travis.yml stdout timeout thing not shutting down properly probably

I don't think so, works fine on master.

[johan-bjareholt]

Things seem to work in the master branch, so maybe merging it into this PR will fix it?

I rebased instead so we avoid potentially breaking master

[johan-bjareholt]

The unstructured commits in the previous version changed the aw-qt version 3 times.
I assumed it was only done once in the only commit which mentioned it, so that's the only one which I rebased before. I now realized that it was more than that. Fixed.

[johan-bjareholt]

Replaced perl with grep in ActivityWatch/aw-qt#53

Hopefully this will work

[johan-bjareholt]

Finally, it's all green!

Merging! 🎆