Page MenuHomePhorge

Make extension installation more seamless
Open, WishlistPublic

Description

Extension installation requires three steps:

  • git clone the repository into phorge/src/extensions
  • arc liberate
  • bin/storage upgrade

For an extension author, a lot of work goes into making sure it is set up correctly. For example, R5 needs DiagramPatchList.php though the code is very reusable. Therefore, I believe we can simply the installation of extensions substantially, perhaps one day allowing for the semi-automated installation of extensions.

Here is what I propose:

  • For an extension to be valid, the extension author needs to run arc liberate on the extension. This will generate /src/__phutil_library_init__.php and /src/__phutil_library_map__.php. In addition, the file src/application/ExtensionNameApplication.php is already required as it registers basic extension information. We will then need to make some adjustments to Phorge to automatically scan and load extensions (rather than arc liberate) that contain these files. This will also allow extension authors to use functions such as phutil_get_library_root() without worrying if their extension is loaded since Phorge will do it automatically.
  • Assume that all SQL patch files are located in src/storage/patch and autodiscover them. Much like core patches, have Phorge raise an error when autodiscovered extension patches aren't applied, prompting an administrator to run bin/storage upgrade
  • Allow extensions to register Monograms programmatically. This would not affect routing or Remarkup (AKA you still need to manually register routes and provide Remarkup rules) but we can use it to handle conflicts. In addition, I recommend that extension monograms be 2+ characters. If extension authors are using one character or have conflicting monograms, show a setup error.
  • Create a "blank extension" that we keep up to date, that extension authors can use as a basis for their own extensions. I recommend we have a simple repository with an empty extension and a ton of comments explaining exactly how to customize the template.
  • Create a Diviner book specifically for extension authors explaining the format and auto loaded information, as well as links to the classes you inherit.

Event Timeline

Matthew triaged this task as Wishlist priority.

I was thinking of adding a script to ./bin to manage (mostly add/remove from load-libraries, maybe also clone) extensions.

  • Allow extensions to register Monograms programmatically

as in, just keep an (automatic) list of monogram-to-extension mapping?

Probably related, I think that any installed extension should not cause any touch to /src/__phutil_library_init__.php, as long as it's versioned in git in Phorge and so will cause of course merge conflicts after any update.

Probably, a __phutil_library_init__.ph could be provided also in the extensions directory, or something separated like that.

I was thinking of adding a script to ./bin to manage (mostly add/remove from load-libraries, maybe also clone) extensions.

You know, I think that's a great idea. We could hook it into upstream if we wanted.

I was toying with the idea of a web-based interface to install extensions, like Wordpress. We'd need to do a ton of work to make that happen, though.

  • Allow extensions to register Monograms programmatically

as in, just keep an (automatic) list of monogram-to-extension mapping?

Yes, internally. This would be as simple as adding a method to ExtensionNameApplication.php which returns an array of monograms, which we can track.

Probably related, I think that any installed extension should not cause any touch to /src/__phutil_library_init__.php, as long as it's versioned in git in Phorge and so will cause of course merge conflicts after any update.

Probably, a __phutil_library_init__.ph could be provided also in the extensions directory, or something separated like that.

__phutil_library_init__.php shouldn't change after an extension is created. Either way, every extension should have its own. I'm not sure adding another file is the solution here, instead I think we can make our extension loading robust enough to handle a change.

every extension should have its own

Ah, yeah, even better I think, if possible

every extension should have its own

Ah, yeah, even better I think, if possible

I believe that is already the case, but I will confirm in the code as I work through some of the changes in this task.