The latest Metalware is currently dependent on Underware 0.3.0, and Underware is currently on 0.4.0 with new changes also awaiting release (and future changes likely incoming before it is production-ready). We should update Metalware to be dependent on the latest Underware instead; what this means in practise will depend heavily on how coupled we ultimately want Underware and Metalware to be.
One thing we have previously discussed is that Metalware should just be dependent on templates, which Underware has the capability to create but which could also be created manually, rather than being dependent on Underware rendering directly. If we go down this route, Metalware would still be dependent on certain more internal parts of Underware (e.g. Underware::SystemCommand, Underware::Utils etc.), which we are mostly using to avoid duplicating this code in multiple repos (though there is also still some Underware/Metalware duplication, where this was trickier to refactor; see https://github.com/alces-software/underware/issues/10). These dependencies of Metalware on Underware could be resolved in various ways, e.g.:
Keep Metalware dependent on Underware-as-a-Gem, but this should just be an implementation detail and have no user-facing effect (Metalware could even install Underware for this purpose itself, rather than being dependent on a local version at /opt/underware and so risking breaking Metalware if this is independently changed). - this is probably the simplest option but it would likely be confusing why Metalware is now pulling in all of Underware to just use a few utility classes.
Defactor these parts of Underware, pulling them back into Metalware and allowing this code to diverge.
Extract a shared Gem for these sort of utilities, which could be depended on by Underware/Metalware/Cloudware etc.
Both 2 and 3 would also mean there would no longer be a need for Underware to carry on being implemented as a Gem, and it could return to being a standard Ruby tool with a regular Gemfile etc. (though there's also not much harm with it being a Gem AFAICS).
The latest Metalware is currently dependent on Underware 0.3.0, and Underware is currently on 0.4.0 with new changes also awaiting release (and future changes likely incoming before it is production-ready). We should update Metalware to be dependent on the latest Underware instead; what this means in practise will depend heavily on how coupled we ultimately want Underware and Metalware to be.
One thing we have previously discussed is that Metalware should just be dependent on templates, which Underware has the capability to create but which could also be created manually, rather than being dependent on Underware rendering directly. If we go down this route, Metalware would still be dependent on certain more internal parts of Underware (e.g.
Underware::SystemCommand,Underware::Utilsetc.), which we are mostly using to avoid duplicating this code in multiple repos (though there is also still some Underware/Metalware duplication, where this was trickier to refactor; see https://github.com/alces-software/underware/issues/10). These dependencies of Metalware on Underware could be resolved in various ways, e.g.:/opt/underwareand so risking breaking Metalware if this is independently changed). - this is probably the simplest option but it would likely be confusing why Metalware is now pulling in all of Underware to just use a few utility classes.Both 2 and 3 would also mean there would no longer be a need for Underware to carry on being implemented as a Gem, and it could return to being a standard Ruby tool with a regular
Gemfileetc. (though there's also not much harm with it being a Gem AFAICS).