| [17:30:03] | * ricardoamaro has quit (Remote host closed the connection) |
| [17:30:53] | * ricardoamaro has joined #aegir |
| [19:31:33] | * ricardoamaro has quit (Quit: WeeChat 2.8) |
| [19:35:52] | * ricardoamaro has joined #aegir |
| [19:37:36] | * ricardoamaro has quit (Client Quit) |
| [19:38:27] | * ricardoamaro has joined #aegir |
| [21:44:05] | * shaneonabike has joined #aegir |
| [23:26:04] | <shaneonabike> | I have a potentially silly question. How are people managing composer files on sites within a d8 platform that require additional modules than the all folder |
| [23:29:57] | <viashimo> | just in composer.json I think |
| [23:30:26] | <shaneonabike> | viashimo: hmmm but do you install a new one within the individual site... like sites/example.com/composer.json |
| [23:30:42] | <viashimo> | ah. I don't think there's a robust way |
| [23:30:45] | <shaneonabike> | viashimo: and the bigger question will it automatically know to use the other composer file or is there magic we have to do there |
| [23:30:58] | <shaneonabike> | cause when we migrate all those requirements get lost |
| [23:31:35] | <shaneonabike> | i don't really need a robust way but something that links the individual requirements of a site to the main composer cause I could see that when we migrate all hell will break lose (all requirements aren't moved) |
| [23:31:40] | <shaneonabike> | Or are they? |
| [23:32:51] | <viashimo> | my understanding of this isn't great, but composer install is run on the platform level to build the autoload php files which are included somewhere (by symfony or the drupal core) so that classes can be loaded |
| [23:33:34] | <viashimo> | and unless something in your composer.json at the platform says to merge sites/example.com/composer.lock, nothing will be included |
| [23:34:20] | <viashimo> | interesting, maybe it can be done with a wildcard entry (https://github.com/wikimedia/composer-merge-plugin) |
| [23:34:26] | <viashimo> | include "sites/*/composer.json" |
| [23:35:56] | <shaneonabike> | viashimo: i guess it also depends on whether drupal decides to ditch sites which is at discuss right? |
| [23:39:59] | <viashimo> | that's my understanding |
| [23:39:59] | <viashimo> | https://www.drupal.org/project/drupal/issues/3004496 |
| [23:40:02] | <hefring> | https://www.drupal.org/project/drupal/issues/3004496 => Improve multisite compatibility with composer [#3004496] => 96 comments, 1 IRC mention |
| [00:13:57] | <colan[m]> | shaneonabike: can you do this with installation profiles? say, each site gets its own profile. |
| [00:15:24] | <colan[m]> | ...instead of having separate module dirs. |
| [00:15:25] | <shaneonabike> | colan[m]: which would then share the main profile? |
| [00:17:18] | <colan[m]> | i'm suggesting you still have the same codebase for all sites (as i think that's what you want), but you'd have `profiles/siteA`, `profiles/siteB`, etc and each site would be installed from those. so different modules would go in each profile dir. |
| [00:17:34] | <shaneonabike> | ahhh ok |
| [00:17:45] | <colan[m]> | we've been leaving towards each site having a separate repo with a single profile, but i'm brainstorming here. :) |
| [00:18:07] | <colan[m]> | this could be a way to keep a single repo with code changes. |
| [00:18:15] | <shaneonabike> | colan[m]: yeah I think that's what everyone is doing but I think that depletes the purpose of having shared code |
| [00:18:41] | <colan[m]> | shaneonabike: right. try my idea and let us know if it works then. ;) |
| [00:18:51] | <shaneonabike> | colan[m]: thanks heaps |
| [00:22:15] | <colan[m]> | hmm. you'd still have a single composer.json though so maybe it won't work. |
| [00:22:39] | <shaneonabike> | colan[m]: viashimo's idea was interesting tho https://github.com/wikimedia/composer-merge-plugin |
| [00:22:50] | <shaneonabike> | colan[m]: but this would need to either be built into the platforms or into aegir |
| [00:23:59] | <colan[m]> | ACTION nods |
| [00:24:56] | <colan[m]> | yeah, they discussed that in the drupal core issue. not much traction there yet. |
| [00:25:11] | <colan[m]> | does sound promising though; someone just needs to implement it. :) |
| [00:25:17] | <shaneonabike> | ACTION feels like drupal is going to dtich multisites |
| [00:26:27] | <colan[m]> | nah, we just need to resolve the composer issue. everyone freaked out then they suggested removing support for it. |
| [00:29:08] | <viashimo> | how do installation profiles work with composer autoloading? |
| [00:29:12] | <viashimo> | ACTION goes to poke around |
| [00:43:23] | <viashimo> | i don't really see much. how does using an install profile help deal with autoloading and other dependencies vs. putting a module in a site folder? |
| [01:24:44] | <colan[m]> | i was just thinking you wouldn't need anything in `sites` folders. that's as far as i got in my thinking. |
