Improve updating mechanism

[MadcapJake]

For some reason, alda isn't updating to latest version. I went in and changed LATEST to 0.5.4 and it downloads the new version, but then if I change it back to LATEST it goes back to 0.5.2. Is there a way to force boot to search for a newer update?

Also would there be a performance gain if alda was installed locally (behind a flag perhaps)? Then, when running alda you could either have it check for a local install or have a flag that skips the update check.

[daveyarwood]

Huh... that's weird. I could have swore that when I tested this initially (by manually installing an old version and then running alda), it pulled the latest version. Now when I try it, it's not working.

@crisptrutski Have you noticed whether or not you've been getting automatic updates?

It would probably behoove us to find a better, more "tried and true" way to handle updates. Maybe in the alda executable, we can catch the alda update command and have it shell out, clone the repo and run boot pom jar install?

[daveyarwood]

On the subject of automatic updates, I think they're kinda neat and have no real problem with them, but I have a feeling that some people might prefer to update manually, so I wonder if it might be smart to move in that direction.

[MadcapJake]

running alda for me takes roughly 5-7 seconds for the repl and 20-30 seconds for a file, how much of that time is spent checking for an update? Is part of that because I have a flakey connection or is that all just clojure overhead? If it's all just clojure, then I don't really see a benefit in implementing a manual update, but if there is some room for improvements by storing locally, then I think it would be beneficial to download (especially for slower rigs and flakier connections). That being said, auto-updates definitely are cool, but maybe just run the update check once a day or something (and add a command for manual updates to the cli for anyone who wants to jump right into a new update).

[daveyarwood]

Wow, 20-30 seconds is really long, even for Clojure. I wouldn't be surprised if the automatic update is adding a lot of time, if you have network connectivity issues. You should be able to test this by changing "LATEST" to a specific version and seeing if that speeds things up -- if that version already exists in your local Maven repo (~/.m2/repository/alda), then it won't waste any time checking for the latest version in Maven Central.

By the way, it just occurred to me that we could more reliably force an update by deleting the user's local Maven repo for Alda and re-fetching the dependency. I tried this locally just now (rm -rf ~/.m2/repository/alda after manually installing an old version) and it did fetch the latest version.

EDIT: Although, I think it would be difficult to programmatically uninstall/delete a Maven dependency locally...

[MadcapJake]

Yeah deleting the repo worked to force an update. Changing LATEST to 0.5.4 shaved about 5 seconds off so it's an improvement. Not sure why clojure is so slow for me, my computer isn't that slow. Six cores at 2.7 GHz. My old fashioned HDD is probably the problem...

[crisptrutski]

Pretty sure I saw it auto update before, and also had no issue building later versions locally and then having them picked up as latest. Last night I also needed to hardcode the version.

Not quite sure how "LATEST" works, for one thing I know last push wins, not the actual version... Perhaps seeing how lein ancient gets versions would be more robust?

Leaning towards a profile.boot file where version could be hard set, or auto update could be opted into.

Also with start up time, perhaps more can be done with AOT? Another brainfart is shipping a CLJS based REPL for super fast startup, that can start reading and parsing while it waits for a playback JVM daemon to boot.

[pkobrien]

Coming at this as a non-musician Clojure programmer, it would be nice to be able to turn off any autoupdating feature. And, I don't particularly like the sound of having Alda deleting anything from my local Maven repo as a way to make something work. Just a thought.

[daveyarwood]

@pkobrien I definitely agree. It sounds like we want to be able to move away from using "LATEST" in the alda start script, and instead replace it with an alda update command that will do it manually. I also like the idea of opting into automatically installing updates via some (optional) configuration file.

[daveyarwood]

A little update -- in the near future, Boot will not be a requirement for running Alda -- we will distribute Alda as a self-contained jar wrapped in a binary executable (likely with a .exe version for Windows users, via Launch4j). Maven won't be part of the equation for the end-user (everything needed to run Alda will be included in the jar), which should solve the issues with "LATEST" randomly not pulling the latest version.

We will include some convenient way for users to update Alda (i.e. an alda update command), as well as a way for users to opt-in to automatic updates.

[daveyarwood]

So here's where we are at the moment:

• Starting with Alda 1.0.0-rc1, Alda is now distributed as a standalone executable that you can download from the releases page of this GitHub repo.
• The whole program is now self-contained in the executable, which is essentially a modified uberjar file.
• To update Alda is to check to see if there is a newer release version than the one you have, and if there is:
  • download it from GitHub (either alda or alda.exe, depending on your OS)
  • chmod it to make it executable (Unix/Linux only)
  • move it to the same path as your existing Alda executable, replacing the older version
• This whole process should ideally be written into the Java client as an alda update command, and should be cross-platform.

I supposed the GitHub API could be used to determine if the latest release has a tag newer than the one you have, and get the path to the download the newer release. One small wrinkle is that the Java client doesn't currently have a notion of what version it is, whereas the Clojure server does (it's a namespaced var in the Clojure source code). We need to make it so that both the Java client and Clojure server can access the same version number at runtime. Maybe we move it to a version.txt file on the resource path or something.

I'm not quite sure how to go about replacing the existing executable with a new one. It seems like the easiest way would just be to do literally just that -- we already have a method in the Java client code which will get the current path of the file that's running, and at least on my system, it seems to be totally possible to delete or overwrite the alda executable while it's running. I guess I just need a sanity check that this is a good idea, or see if anyone has a better alternative.

We could, and probably should, also maintain Alda in package managers (Homebrew, etc.) starting when we release version 1.0.0.

I'm currently prioritizing other things, but if anyone feels like taking a stab at this in the meantime, please feel free!