In order to include this module in Aegir's "golden contrib", we'll need a full release. Also, it is a dependency of a sub-module in hosting_distribution, and so blocking a full release there too.

Comments

ergonlogic created an issue. See original summary.

helmo’s picture

helmo CreditAttribution: helmo at Initfour websolutions commented
Title: [meta] 3.0 release » [meta] 3.0 release of Aegir Composer
Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location New Windsor NY
CreditAttribution: Jon Pugh at OpenDevShop Inc (CLOSED) commented

I like the direction that hosting_platform_git and hosting_platform_composer are going here, but it is confusing to have these modules in a project named "hosting_composer".

These two modules would be much better served being included in hosting_platform itself, in https://www.drupal.org/project/hosting

If these are the pluggable systems for platforms, why shouldn't they be in the base system?

https://www.drupal.org/project/hosting needs love. Why doesn't hosting.module deserve to have awesome code like this in it?

Let's at least leave this open to feedback? Everyone I know wants this functionality in Aegir. It's essential to how Drupal is done today.

I don't see any reason to not use awesome code like this to make Aegir core better.

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location New Windsor NY
CreditAttribution: Jon Pugh at OpenDevShop Inc (CLOSED) commented

A perfect example: I just learned of this "Aegir Objects" module? https://www.drupal.org/node/2876246 I don't even know what it does.

Why are we creating so many different contrib projects for this? We are creating so much more maintenance for ourselves and it's just plain confusing.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented

These projects just aren't mature yet. I agree that they should be included in core, eventually. The whole point of golden contrib is to facilitate broader exposure of such new feature, to garner more feedback and testing. It allows users to opt-in to new or experimental features, while maintaining the stability (such as it is) of Aegir core.

Sticking these sub-modules in hosting_composer was exactly intended to minimize the number of new contrib modules (at least as far as full-blown drupal.org projects)

While I hope that they'll be useful in Aegir 3.x, I was also experimenting with techniques that were relatively new (to me) to help address things like #2043419: [meta] Re-think our object models & design patterns, #1455216: Implement the base Hostmaster objects as entities, #2715233: [META] Improve Hosting/Provision Services API, and #2049583: [meta] Modernize our code-base.

Aegir Objects is basically an API module that provides some base classes to simplify some common things we do in Aegir, like modifying forms and nodes. hosting_composer and hosting_distribution then extend those classes. So, basically, DRY.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

I like the direction that hosting_platform_git and hosting_platform_composer are going here, but it is confusing to have these modules in a project named "hosting_composer".

I was wondering about this too. Why not merge this module (and submodules) into Aegir Distributions? It seems strange that some methods are included in that module while others are in Aegir Composer (here).

If these are the pluggable systems for platforms, why shouldn't they be in the base system?

That would be mostly for the reasons outlined over at https://www.drupal.org/node/2884048#comment-12257663. However, given that this stuff is indeed framework-ish, putting it in core doesn't seem unreasonable. Why don't we start with placing it in on the Golden list first to get it stabilized & integrated, and then consider moving it to core afterwards?

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location New Windsor NY
CreditAttribution: Jon Pugh at OpenDevShop Inc (CLOSED) commented

Ok, good to hear we are open to this.

I'll review these projects when I start to think about moving even more of DevShop into Aegir, but for now, we've just put so much effort into hosting_git recently, were going to have to stick to using that for now.

An aside, we should start adding behat tests for these features to help mature them.

Thanks for your efforts here!

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented

Why not merge this module (and submodules) into Aegir Distributions?

Because they do different things and each can be used completely independently of the other.

I think the confusion may arise from the submodules under hosting_composer: hosting_deploy, hosting_platform_git and hosting_platform_composer. The first is just UI cleanup, whereas the other two are new(ish) mechanisms for deploying platforms. If anything, they should perhaps be re-organized as submodules of hosting_deploy, which itself should perhaps be renamed hosting_platform_deploy.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

I suggested a rejig of this stuff in #2938992: Enhance composer support in Aegir core; let's discuss over there.