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

Bundle two different themes (for hub and for project) with shared logic #20

Open
strogonoff opened this issue Jul 20, 2018 · 0 comments
Assignees

Comments

@strogonoff
Copy link
Contributor

strogonoff commented Jul 20, 2018

This is a tentative idea to replace one multi-purpose conditional-ridden theme with two simpler themes, one for open project and one for open project hub.

This should be a good idea as long as it’s possible to have:

  • Themes reuse shared logic through helpers gem
  • Project sites inherit shared aspects of hub styling from parent hub (e.g. by pulling SCSS variables file)
  • Reduce duplication of template code to let’s say fewer than 100 LoC, since this appears to be the part least obvious in terms of reuse across themes

Two distinct theme gems is the most obvious way, but this might add a bit of headache in terms of gem versioning. There may be an alternative way to have this sort of separation without creating a separate theme gem.

Thinking a bit ahead

As an open site suite maintainer (as opposed to theme developer), I’d want to just give AWS credentials, point to repositories containing project & hub data along with styling variables, and have the whole open site suite provisioned without worrying about gems & their versions. I might want to be able to pin theme version in case my project data is in old format, but that’s about it. I don’t want to be ensuring all sites use compatible theme & helper gem versions, etc.

With that in mind it seems like a natural way to handle the whole site provisioning in most developer-friendly way could eventually be through a topmost developer-friendly layer in the form of, e.g., a Terraform project or a Docker image/Dockerfile.

This would make data management more straightforward (repos would not contain Gemfiles, lockfiles, etc.) and it would enable the Open Project project developers to focus on optimal gem structure without worrying about complicating version management for Open Project project consumers. It would shift some of the responsibility of version management and deployment orchestration from Open Project consumers to its developers.

The challenge may be picking the best way to bundle the orchestration, since TF may not be everyone’s choice, although I don’t see why not.

This section is somewhat related to #9.

@strogonoff strogonoff self-assigned this Jul 20, 2018
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