Background

[macMikey]

This repo started with Issue 132 on the Levure repo. Those comments are copy/pasted as part of this issue.

[macMikey]

(me) With dataviews, dataview trees and other helpers, we are probably at the point where we need to add some sort of installer for these components. Perhaps this should be a separate repo to keep the bloat out of the main framework, since it will probably have a UI, and code. On the other hand, that makes it harder on the developer when they are trying to add something to their project.

Dataview Trees (DVT) require the installation of the dataview (DV), but having that be a submodule of the DVT might be problematic, especially if the project already has DV installed. Installer needs to:

• Add the primary...stuff. For helpers this would be all the resources for the helper. • Determine if there are any dependencies and install those if necessary (or at least prompt to install those). In the case of DVT, that would be DV. If the dependencies cannot be installed then the primary component should not be, either. • We might need some versioning...stuff. For example, if we are adding DVT, which requires DV, we may require DV to be of a certain version. That would mean that helper.yml, for example, would have to have a version key so we can tell which version it is. • Log install activity • Need a way to rollback if we get a failure during the install • Option to update app.yml with any relevant sections that might be relevant for the component(s) (nicety for the developer) • Option to update submodules for the project, if git is in use • The installer should be trivial to configure, preferably via a yml file, and potentially .livecodescript files, which will also make it simpler to debug when someone is trying to install a component. Perhaps there should be an installer folder inside the component. • Dependency evaluation should be part of initializing the helper (in interpreted) or built (in compiled), just in case something bad happens later (e.g. developer updates the DVT submodule but that requires DV to be updated, but the developer doesn't update DV).

[macMikey]

(trevor) Nice overview @macMikey. This should definitely be in a different repo. Let's keep this repo focused on the framework itself.

One other thing to consider is how the installer will locate helpers that can be installed. Without a central repository they would need to manually enter a url somewhere.

For starters the installer repo could have a database file that points to all available helpers. This database file would point to the helper download link. It would also need a url to a file with version info and dependencies. Perhaps we just add this to the helper.yml file.

A more advanced version could be like https://packagecontrol.io which is used for Sublime Text. That requires additional costs though so I don't think it is wise to start there.

[macMikey]

(me) That's if we use a central installer, which is certainly an option in the future. I was initially thinking about having the installer be invoked when someone wants to add a particular component. Do you want to start a repo for this project or should I?

[macMikey]

(trevor) How are you thinking about resolving dependencies then? Does a helper have to define the full url on where to find any dependencies? That would mean that if a helper url changes then any helpers that depend on it will need to be updated. That can be fine at first but it is something to consider.

I suggest you create the repo for this.

[macMikey]

(me)

I think we should have a couple of phases of implementation, since we don't have a bunch of components to worry about yet (and until DVT we didn't have a real need), and right now speed of getting it done is better than super-duper. Phase I would be the hacked-together-component-by-component handling, with the full URL specified somewhere as part of the installer.yml (or equivalent) file Phase II would be having a central "db", with full URL's. Then each installer would reference ID's in the DB. Phase III would be a Levure Lifestyle Mall with descriptions and pictures, and curvy brick walkways, and nostalgic streetlamps, and nummy restaurants, and stores that are for browsing only, because you ain't buying a pair of $5,000 ankle socks.

[macMikey]

Maybe some day ("phase 3"), the installer will be fork-agnostic, i.e. if I fork the project and run the installer it will use my fork instead of the main one.

[macMikey]

Phase IV? Maybe add some stub handlers as an option with some components. Example:

on resizeView pWidth, pHeight
   ` called when resize a card.  Use to handle resizing of DV and DVT
end resizeView

The problem with that approach is that you can't be sure which card (or behavior SOS) will be for a DV or DVT. If the installer places a component on a particular card, then we should think about this. However if the DV/DVT is added to a project, probably not. Instead, the IDE component that does the installing should do it.

[macMikey]

Just in case I forgot, above, helpers need to be explicitly called out in the helpers section of the app.yml file.