Rewrite in Go!

[fubarhouse]

This still may or may not proceed depending on the outcomes of the prototype I've been working on. There are some conventions I'd like to try to prevent using before this goes into git.

The program can now be viewed on the branch dev-2.x.

Structure preview

Currently needs work

• [x] Convert the main system to an OOP golang variety
• [x] Install methods
• [x] Reinstall methods
• [x] Uninstall methods
• [x] Get/set value methods (needs thinking to make better use)
• [x] Create class to store version lists
• [x] Ensure lists are populated
• [x] Ensure the application works with composer-based versions
• [x] Ensure the application works with non-composer-based versions
• [x] Package management functions/methods
• [x] Functions to fetch local installations
• [x] Functions to allow user input to program
• [x] Write go tests
• [x] Documentation

Roadmap / Things to do

• Complete documentation
• Add additional features or attempt to as described below
• Add any applicable interfaces and test
• Convert wget/unzip tasks to use things the Go way, and not using wget/unzip (see #71)

Additional features under consideration

• Dynamic tag fetching instead of storing versions in static variables. (see #72)
• Improve the new flag system (see #70)

[fubarhouse]

So the version management aspects are quite solid, other than the work to be done above.

I've segregated the entire system into many useful chunks, and even added some more, and I've started rewriting another program I maintain which uses bash to choose and run commands... It's a part of a much larger package which is a much larger scope Drupal management program for Linux.

This go rewrite has so much extra scope that this control system will likely be sucked into that, but the dvm program could simply be a project with imports dependencies which accomplish this refined task whilst keeping so many other useful drush things in one place.

The future is looking amazing, but I've a hell of a lot of work to do if I'm to proceed in any direction. Benefits of writing the extra stuff (a rewrite of the scripts I use at work) would include platform independence (huge win), ability to test the code (woot), readability (especially when converting sed commands) and project structure in general.

Again, I'm not certain how far down this rabbit hole I'll go - but I'm competent at a brand new language for it, the only things left in golang which'll really benefit me would be the templating system which will need work for some components.

[fubarhouse]

I don't believe I'll bother with travis tests in the initial release.

In all seriousness I'm happy if the test files pass and are publicly available for others to test when debugging - I'd prefer to get this out sooner as it's a significant improvement over the existing shell-based system.

I'll look into getting the documentation up to scratch tonight, open a ticket for the new flag system as I'm not completely happy with it - and start a bit later on the ansible role.