DepCtrl Post-v0.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 LuaCATS
• [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.

[line0]

I have decided to abandon the idea of using an SQLite backend as an installed package registry for the time being because:

1. From v0.7.0 on, DepCtrl no longer depends on any of the previously required native libraries (BM, DM, PT) that needed to be compiled and shipped for every platform (they weren't) - in favor of native OS APIs or libraries that are already ubiquitous (e.g. libcurl and OpenSSL on Linux). Adding SQLite as a hard dependency would have been a step backward in that regard.
2. With v0.7.0, concurrent config file access is now handled much more gracefully and also much faster (compared to v0.6.4, not to speak of the SQLite branch.

The package install hooks, file tracking and atomic install/uninstall will not make it into v0.7.0, so I'll split them off into a new issue.