Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Metalware to use latest Underware #460

Open
bobwhitelock opened this issue Dec 18, 2018 · 0 comments
Open

Update Metalware to use latest Underware #460

bobwhitelock opened this issue Dec 18, 2018 · 0 comments

Comments

@bobwhitelock
Copy link
Contributor

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 openflighthpc/flight-architect#10). These dependencies of Metalware on Underware could be resolved in various ways, e.g.:

  1. 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.
  2. Defactor these parts of Underware, pulling them back into Metalware and allowing this code to diverge.
  3. 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant