As per this TODO in the README, I'd like to propose a method of overriding the packages downloaded and parsed by the install profile. This is currently in support of #2018761: Upgrade api.aegirproject.org to D7, but it'd also be great if it allowed me to Create an API-reference website for Backdrop.

Comments

ergonlogic’s picture

What I propose is using a couple makefiles to both separate out the parsed code from that used on the site itself, and to allow for easier overriding. The idea would be to move the core and documentation packages from the drupal-org.make, and put them in a core-docs.make. This can then be included back into drupal-org.make via another makefile: sources.make, which would essentially just have:

includes[] = core-docs.make

This should allow anyone wanting to override the parsed projects by adding a new makefile, and either adding to or replacing the include in sources.make. This should allow for a pretty clean and maintainable patch/sandbox.

In drupalapi_api_setup(), sources.make could then be parsed for the appropriate includes, which would in turn parse core-docs.make and/or whatever others had been patched into the platform. We could build these libraries under a 'sources' directory to simplify update.sh. Alternatively, update.sh could be turned into a Drush shell script, and the makefile reloaded directly.

I haven't tested this yet, so it might not work at all. But i'll be hacking on it a bit today and let you know if it pans out.

ergonlogic’s picture

The idea is to allow a project to maintain one or more alternate/additional makefile(s) to include in sources.make, a patch to override the contents of sources.make, and the a new stub makefile that would apply the patch to DrupalAPI. Ideally, the patch would be unnecessary, and this could be handled directly in a new stub.

ergonlogic’s picture

BTW, I'll work on this over in the dev/2116731 branch of my sandbox.

ergonlogic’s picture

So, it turns out that we can add arbitrary data to Drush Make arrays, and Drush will just ignore any keys that it isn't aware of. As such, it looks like we can use drupal_parse_info_file() to parse (simple) makefiles. So, the plan in #1 is looking plausible.

ergonlogic’s picture

Assigned: ergonlogic » Unassigned
Status: Active » Needs review

See dev/2116731 e3504a3 for the foundation of this change.

ergonlogic’s picture

Obviously, there's room for improvement. Next step is to see to what extent this allows for overrides.

ergonlogic’s picture

This is working more or less as I had originally planned. See my other sandbox for an example of how to override the included Drupal source makefiles: https://drupal.org/sandbox/ergonlogic/2118185

Basically, the way it works is that it includes a stub makefile that's pretty much identical to the drupalapi one, except that is applies a patch that replaces the include in .sources/sources.make to point to a couple makefiles from the sandbox's git repo. I had to adapt drupalapi_core_get_projects() to handle remote includes to support this.

I'd tried to have the stub.make point to raw git output to get the patch as well, but that doesn't appear to work. So I added it to an issue instead, and all is working as expected.

I figure to build a small feature to configure the API site the way I want, and just include the current bits in there.

ergonlogic’s picture

There are probably a couple more things to adapt. Like the front-page isn't currently set to the preferred branch.

But this even works when simple adding the stub.make's raw git output into the 'makefile' field on an Aegir platform node.

Deciphered’s picture

Issue summary: View changes
Status: Needs review » Fixed

Merged and pushed.

Thanks for the hard work.

P.S., updated the frontpage variable as well.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.