DepCtrl 0.7.0 TODOs

[line0]

With most of the under-the-hood changes finally done, it's time for a new DependencyControl release.
This ticket tracks the remaining work to be done for 0.7. Feel free to help with any of these tasks or propose additional items, but keep it limited to urgent fixes, improvements and things that would be difficult to add later.

Minimal scope

• [Feature] SQLite database migration tools: allows incremental database schema upgrades both using .sql files and post-install hooks (see below)
• [Feature] Package install hooks: let a package perform tasks after it has been installed or updated
• [Feature] Package file tracking: keep a record of which files have been installed by a package, including hashes (required for proper uninstall support, see below)
• [Improvement] Safer package uninstaller: current implementation deletes possibly unrelated or modified files, both of which may be undesired
• [Lifecycle] API documentation updates: API should be fully documented using LDoc
• [Lifecycle] Compatibility testing: test known scripts using DepCtrl for compatibility issues
• [Platform] Include lsqlite3 builds: DepCtrl 0.7.0 requires LuaSQLite 3 so we need to provide the native libraries for Windows, OSX and Linux
• [Feature] Enum class: DepCtrl now uses tables as stand-ins for enums in many places. Provide a class that adds some safety against typos and helper methods to get string representations of numerical values.
• [Bug] Fix DM, PT binary file name in OSX release archive (see Error installing DependencyControl scripts #8)

Optional

• [Feature] Custom Menu configuration: The feature needs to be upgraded with a DepCtrl Toolbox GUI and per-macro configuration.
• [Improvement] Load time optimizations: With the new SQLite backends reloading automation scripts takes some 15-odd seconds with about 70 installed packages. There are still some tweaks and improvements to reduce database contention and speed it up another few seconds

[CoffeeFlux]

Pinged you about this on IRC, but I'm going to move it here to see if you're still interested in having this happen.

I began the process of documenting the files with LDoc but discovered that it doesn't work properly with private methods in Moonscript. Given that LDoc hasn't seen commits for over a year, I'm highly doubtful that this is going to change. I'm still willing to document this since I think that's useful, but not sure how you want to approach that.

Additionally, is there anything I should know about how you wish to handle file tracker the and proper uninstall support before I start implementing that? One immediate question that comes to mind with the uninstaller is how to handle packages install before 0.7. I think the two main approaches would be to record modified files moving forward and revert to old behavior when an old script is uninstalled, or to forcefully uninstall and reinstall all script with the 0.7 update to get inevitable problems out of the way.

What do you envision for the format of the post-install hook? I agree it's a good idea, but I'd like an idea of how to use it from the perspective of someone writing a script before I write any code to that end.

On the subject of offering builds, can you make your installer scripts available somewhere, even if they're messy? I'm happy to clean them up, but Aegisub has seen recent updates and I'd like to be able to offer my own updated depctrl-bundled builds. I can write my own from scratch, but that seems unnecessary.