Packaging: document custom modules and themes in profiles

Where should this information go?

A) Developing installation profiles is the root of the handbook tree that seems relevant, although that page itself isn't the right spot.

B) Packaging a profile on drupal.org is the specifics about packaging distros. I guess that's the right spot, but it's a bit off. That page is talking about how to use .make files to bring in other things. What you're talking about here is standard/recommended practice for developing an install profile that it's okay to have a profile-specific module that lives inside the profile. That's really a devel question, not just a packaging one. But, they're obviously related.

Anyway, if someone wants to take a stab at some text for this, and/or comment on where this text should live, that'd be great.

Thanks,
-Derek

tags

I'd be happy to update this documentation if someone could either describe the correct place within a profile project repository to put modules and themes, or point me to an example distribution that already uses this technique where I can see an example.

Looks like you can commit directly to /modules and /themes directly inside the profile project's repository, and this will all show up at /profiles/myprofile/modules and /profiles/myprofile/themes when packaged with Drush make.

tagging the Distributions issues so the issue triage avoids closing this issue

A current text from Packaging a profile on drupal.org is:

As a profile maintainer, all you have to check in to Git is the .make file, and the packaging script will automatically assemble all of the modules and themes it references when creating the downloadable file archive for a given release.

To fix this issue, it could be replaced with a more complete text like the following. Is this all right?:

No copies of existing contributed projects should be checked in to the Git repository. As a profile maintainer, all you have to check in to Git is the drupal-org.make file, and the packaging script will automatically assemble core and all of the contrib modules and themes it references when creating the downloadable file archive for a given release.

Custom modules, features, and themes are managed differently to contrib. You can commit all custom to modules/ and themes/ directly inside the profile project's Git repository, and this will all show up at /profiles/profile_name/modules/ and /profiles/profile_name/themes/ when packaged with Drush make.

You can organize contrib and custom in subdirectories of modules/ and themes/ with any name you choose, such as contrib, custom, features... For example, define drupal-org.make attributes like projects[views][subdir] = contrib which tell the packaging script to place contrib modules in modules/contrib/. And commit directly custom modules to modules/custom/ and custom features to modules/features/.

Oops, crosspost. It looks like webchick is working on that page right now.

Tagging. This is part of the community initiative on Distribution Packaging.

Or maybe with the code tag, and making clear that procedures for contrib and custom are different:

No copies of existing contributed projects should be checked in to the Git repository. As a profile maintainer, all you have to check in to Git is the drupal-org.make file, and the packaging script will automatically assemble core and all of the contrib modules and themes it references when creating the downloadable file archive for a given release.

On the other hand, custom modules, features, and themes are managed differently to contrib. You can commit all custom to modules/ and themes/ directly inside the profile project's Git repository, and this will all show up at /profiles/profile_name/modules/ and /profiles/profile_name/themes/ when packaged with Drush make.

You can organize contrib and custom in subdirectories of modules/ and themes/ with any name you choose, such as contrib, custom, features... For example, define drupal-org.make attributes like

projects[views][subdir] = contrib

which tell the packaging script to place contrib modules in modules/contrib/. And commit directly custom modules to modules/custom/ and custom features to modules/features/.

Note: although Packaging a profile on Drupal.org is still probably the best place to document this, another possibility is to talk about it over at Managing Drush make files for an installation profile.

Anyway, I mostly liked juan_g's text, but it needed a lot of edits and better formatting. So, I just put an enhanced version of the text at the Step 5: Committing and releasing section:

http://drupal.org/node/642116/revisions/view/1941904/1942014

Therefore, calling this fixed. Feel free to reopen if anyone thinks this is the wrong place to explain this.

Thanks!
-Derek