Improve installation process

[veswill3]

At the moment, the installation process is just putting the files into the correct spot and making them executable. There is no solid process for applying updates. I was wondering if there was some simple way to update the process so that pulling in updates was easy? I would do a pull request, but I am no unix pro so I figured I would ask for advice first.

Asside from this being part of the mainstream package managers, my first thought would be to check out the git repo, so that you can git pull on it, then symlink notes into /usr/local/bin/notes and notes.bash_completion to /usr/share/bash-completion/completions/notes. Would this cause issues or be difficult to maintain? I guess this would assume the user has git installed...

Down the road you could even apply some sort of auto-update process. If it becomes part of a package manager then it would be built in, but if we did something like the above idea with git it could do a git pull in the background when you run the notes command every so often. Maybe the notes script could check for updates and curl them in automatically so it does not rely on git.

Thoughts?

[pimterry]

Yes, that sounds excellent. I'm very open to ways to better distribute this.

First, thoughts:

Having git as an option is fine, but I don't think it should be the main one. Firstly because the git repo contains a bunch of things that are irrelevant to users (the tests, the full repo history, etc), and also because it requires you to manually think about releases yourself as an end user. You probably don't want to be on master, but that is what you want to get by default if you clone the project. Instead you want to be on the latest tagged release. And on top of that, yes, being tied to git will be a bit inconvenient for some users.

We could build an install/update script without git pretty easily, because Github gives us most of the information anyway. You can easily query github for the latest release (curl -s https://api.github.com/repos/pimterry/notes/releases/latest), get the tag (grep tag_name | ...), and pull down the latest version of notes (curl https://cdn.rawgit.com/pimterry/notes/$TAGNAME/notes > /usr/local/bin/notes). That might be a reasonable starting point. Need to think about what happens when the list of files to download changes. Maybe a script that downloads a manifest of files and locations first, which potentially changes per-version, and then installs what it's given.

Looks like just moving to the Bash Package Manager might get close to this.

In a perfect world, I'd like a separate distribution channel that we explicitly push releases to (potentially automatically by pushing tags to github), that contain only the files that end users actually care about (i.e. notes and notes.bash_complation), and which automatically handles updates by integrating with normal system updates, rather than notes having to trigger updates separately. Proper package managers will also do things like uninstalling and prompting users for updates nicely all for us.

To do that, we'd want native per-platform packages (RPMs, DEBs, whatever you need to publish to homebrew, etc). Notably we're already published to the Arch User Repository (see #7) - that's a package that internally manages it's own updating with Git, which is a bit crazy long-term, but works for now.

Building our own packages is harder, but probably not that hard. fpm should let us build them, and then we'd need scripts to automatically push the results to each of the relevant distributions channels.

[pimterry]

So, given that wall of text, where should you start. If you're interested, trying doing one of:

• Seeing what the Bash Package Manager actually gives us, what it doesn't, and how much work that might be to publish to.
• Writing an install script so that users can do something like curl https://cdn.rawgit.com/pimterry/notes/master/install.sh | bash and get the latest version up and running (and then do the same again later to update). Needs to think about making sure updates work, and handling later changes to the set of files we publish in releases (e.g. when zsh completion gets added), etc.
• Trying to build a package for one platform (e.g. deb), working out how automated publishing would work for that kind of package, and then trying to work out a way we could easily do that automatically when we want to do a release (which we can expand to cover more platforms later).

They're approx that order of difficulty I think. Let me know if you're keen, and where you want to start.

[veswill3]

Great! Let me read up on each of these and see what I can do.

[veswill3]

I think haveing platform specific packages (deb, rpm, etc) that are integrated into the package managers (apt, packman, etc) is the right way to go, but I started looking at the documentation and I think that is a bit out of my league at the moment, even with fpm.

bpkg would provide an easy option, but that is yet another tool to install. It would be pretty simple to add later on, but I dont think it is the way to go at the moment.

It sounds to me like the best option for right now would be a setup script to run remotly via curl. I can get to work on this and submit a PR, but I have a few questions first:

How do you want to handle updates?

• Encourage force users to stay with the newest version via background auto update?
• Prompt if they want to update to the newest tagged release, or only for major version releases?
• Add an update command that checks and does the update?

What do you think about this update process? The notes script has code that knows how to uninstall itself and how to remotly run the setup script so that if the list of files or dependencies change it can clean itself up and invoke the new process.

[pimterry]

Phew, exciting. Ok. I'd rather not integrate the updating code into notes directly, largely because it's a big can of worms, especially if you get real package managers involved too later. Even in the existing arch case for example, it seems like it's going to be really easy to accidentally end up with two independently managed install on your machine, and to not be able to track down or uninstall them again cleanly in future.

I think that rules out auto-update and active prompting for now. We should start with a simple script that just does installs of the latest version, and build everything up from there. Once we've got that in place, we can build up notifications and autoupdate on top very easily.

I'd aim to first write a script that:

• You can curl and run one command to get an immediately working notes setup on a clean typical machine on the latest version
• You can curl and run again to update a notes setup on a typical machine that ran the script before to the latest version
• Prompts if it's not sure what to do about anything (e.g. confirm before overwriting /usr/local/bin/notes)
• Outputs the list of files created afterwards, for manual uninstallation (we can do nice uninstalling later)

'Typical' includes at least normal Ubuntu installs and OSX with GNU tools installed. Latest version is defined by releases on github. If there's more you want to strip out of that to keep it even simpler, feel free.

Later steps might include:

• Prompting for updates
• Doing bash (and zsh: #33) auto-completion automatic installation as part of this
• Uninstalling easily
• Installing not the latest version
• Listing changelogs and new features when you install
• Integration into proper package managers

But we don't need to worry about any of that to get a useful working first step in place, and we can then start building from there.