search

pharo-project / pharo-launcher

Lets you manage your pharo images and download new ones
https://pharo-project.github.io/pharo-launcher/
MIT License
108 stars 46 forks source link

Enh vm image custom hooks #502

Closed seandenigris closed 3 years ago

seandenigris commented 3 years ago

Introduce hooks for custom VM and Image Subclasses, which can specify their own e.g.:

As a working use case example, PharoLauncher-GToolkit allows predownloaded Gtoolkit VMs and images to be used via Launcher.

Manage GToolkit images:

  1. Download a GToolkit VM/image bundle
  2. Put the VM and all libraries into a folder of the form gt-[version]-architecture where version is the GToolkit image version e.g. gt-0.8.83-x64. The reason that we use the image version is that the GToolkit team made it clear (Discord -> GT -> General on 8/28/2020) that for the time being, the VM may change with every image version. No assumptions can be made about compatibility other than that.
  3. Place the created VM folder in the same folder with the other Launcher VMs
  4. Rename the image and changes file to the same base name as their parent folder (e.g. if you downloaded GlamorousToolkitOSX64-v0.8.83, then GlamorousToolkitOSX64-v0.8.83.image
  5. Create a pharo.version file containing gt-[version] e.g. gt-0.8.83 (i.e. the same as the VM minus the architecture)
  6. Move the downloaded folder into the folder where your Launcher images are kept
  7. Open or refresh Launcher. The image should appear
  8. Select the image in Launcher, bring up its context menu, and "Create Template" and go through the dialogs

The template should now be available to create new images.

NB: Didn't add PharoLauncher-GToolkit to the baseline. Should we? There are no dependencies except Launcher, so it can be easily loaded on top of Launcher. Maybe we should at least define the package so that it can be loaded via MetaC API?

seandenigris commented 3 years ago

@demarey Any idea what the CI error is about?

demarey commented 3 years ago

Hi Sean

Nice addition! Than you! In addition, I like the refactoring you did with #asPhLImage (avoids an ugly code).

The CI error was caused by an old OS X slave that cannot run a recent Apple Script for packaging. tests are now green.

I think we should add the new package to the baseline and maybe in the default loading group. Do you see any reason to not include it?