Evaluate - Find solution to get dependencies declared in express.info into the site's codebase

[kreynen]

I thought Bee would allow us to quickly ddev bee dl the current, supported module releases, but that isn't working with DDEV to be able to do that before the Backdrop install the way I'd hoped. Not sure if that's a limitation of Bee, Bee on DDEV or I've just configured it incorrectly. The way it is now, I end up with an order of operation issue. I can't install Backdrop with the Express Install Profile because the dependencies aren't available. Adding https://github.com/backdrop-contrib/express/blob/main/express.info#L37 results in...

I have to install Backdrop with the standard install profile, manually add each dependency, then drop the db and config and finally do a clean install of Express with the dependencies in the codebase.

In D7, we used drush make to add both Drupal dependencies and third-party dependencies to the profile. This would often result in duplicate copies of modules in the codebase. D7 handles this by trumping lower level copies when the same namespace was defined at a higher level; profile > site > core. This never smelled right.

I've tested placing modules into core/profiles/express/modules and that works, but it would be better to find a way to get the dependencies needed for a profile into the normal /modules directory so that they can be updated with the normal Backdrop process.

In https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/Distributions/near/306103820 @hosef wrote...

Since we now have a project installer built in, I think that could be extended to enable distribution like behavior without the headache of requiring distribution maintainers to update all the modules every time new releases are created. Essentially, you can just make a dependency list and the project installer should be able to handle the rest for you.

Longterm, I think that would be an ideal solution and similar to how Drupal Recipes will work, but I don't know what level Backdrop is bootstrapped when it discovers the install profiles. There will also be dependency tree issues similar to the problems Composer 1.x had with larger project. Express declares a dependency on module X which declares a dependency on module y which declares a dependency on module Z. That's tolerable for a single project, but to click through that 20 times doesn't really seem like an ideal Site Builder experience. You could solve that by moving all the dependencies into the profile's .info and processing them in order from lowest to highest... but then we'd be rewriting parts of Composer dependency tree processing. Might be an option, but it seems like a lot of work what is currently an edge case.

I think a more elegant solution might be a Bee pugin that processes the dependencies in the profiles .info before Backdrop is installed.

[yorkshire-pudding]

Hi @kreynen . @stpaultim alerted me to this issue.

I tested this with lando
I downloaded core, then:
lando bee dl realname
lando bee dl express
lando bee si and entered options entering express for the profile to use.

This worked. We do have a feature request in the bee queue (backdrop-contrib/bee#188) for bee to be able to download dependencies. bee can currently enable dependencies if they are downloaded but doesn't do the download bit. At some point I hope to get to it, given I raised that feature request, but if you fancy tackling it, collaboration is welcome.

[kreynen]

@yorkshire-pudding Thanks for clarifying that the bee dl should work before bee si. These are the type of things I struggle with not having much experience maintaining with Backdrop.

For the short term, I think I'll just write something (a script? a bee extension?) that will generate the list of bee dl's from the express.info and use that to we'll use to maintain a fork of https://github.com/backdrop-ops/backdrop-pantheon as a Pantheon Upstream. I thought about using Pantheon's composer build process with Backdrop and a "super module" approach to enable Express after a Backdrop Standard Profile install, but I don't think it's currently realistic to install a module with 30+ dependencies (and the dependencies of those dependencies) using the Project Installer.

[johnquest]

@yorkshire-pudding @kreynen I tested in ddev. The ddev bee dl command is working in my install but only after installing a site, not before.:

ddev bee dl realname
ddev bee dl field_group

[yorkshire-pudding]

@kreynen @johnquest - you might like to take a look at the PR I've got against backdrop-contrib/bee#188 as this should handle the downloads. It all works without backdrop being bootstrapped so should work pre-install.

[yorkshire-pudding]

but only after installing a site, not before.:

@johnquest - did you navigate to the backdrop root folder? I'm surprised that it doesn't work; AFAIK, ddev is based on docker, which lando also is, so I would have thought they would both be fine.

[johnquest]

@yorkshire-pudding Yes, the dl command works. The error I was seeing had something to do with the fact that I was connected to my vpn network, but interestingly it works now while connected to vpn. I tested both from the global install of bee outside of docker and with the ddev bee dl command from within the webserver container and both work on Linux.

[yorkshire-pudding]

@johnquest - so have you now been able to download projects before site-install?

[johnquest]

@yorkshire-pudding Yes.

[yorkshire-pudding]

Hopefully the PR I mentioned above will enable you to get all the projects you need as part of your install profile.

[kreynen]

I may be the outliner here. I'm trying to install Backdrop with Composer so that we can use the simpleSAMLphp library installation and configuration process we defined for https://github.com/cu-uis/cu-starterkit-project/wiki/Building:SAML-Configuration. Stanford has a more manual configuration process they've documented for D7 and D8 at https://opensource.stanford.edu/sunet-authentication-drupal-using-simplesamlphp. My hope is that we'll be able to leverage Pantheon's new secret management solution and can just treat that Backdrop sites as just another flavor of Drupal.

I'll give this another go sometime this week.