Policy Question: Can I Use a Submodule that Does Not Follow Drupal Code Guidelines? I have a fairly extensive plugin system that I wrote.

It uses an MVVM pattern, where the lions' share of the code is in a cross-CMS class.

I haven't submitted the Drupal plugin to the Drupal repo, because it does not follow their coding conventions.

It has extremely rigorous coding conventions; just not the ones prescribed by Drupal.

Fair enough. They have every right to dictate coding standards. That's a good idea, and I support it.

However, I can't rewrite the MVVM library to make just one of the targets happy.

Since the MVVM library is actually a submodule, can I submit the plugin to the Drupal repository if the Drupal-specific parts (just a couple of files) are set up to use Drupal standards?

For that matter, since Git is so horrible with submodules, I wonder if the Drupal repository can even handle submodules.
Since the MVVM library is actually a submodule, can I submit the plugin to the Drupal repository if the Drupal-specific parts (just a couple of files) are set up to use Drupal standards?


Yes, as long as your Drupal project conforms to the GIT repo policy - where just one of terms are: "All code should comply to the coding standards." you can commit it (such projects are known as "bridge modules") to the Drupal repo (provided you have the access level required to do so - the access bar is low for sandboxes, but a lot higher for full projects). Note: You should only commit the Drupal-specific part.  The rest has to be hosted somewhere else.  Tell your users how to find it, and how it shall be combined with the Drupal-specific bridge.

However, there are other terms, and it looks like the BMLT License, as it currently appears, is a blocker:


  "BMLT is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version." (my emphasis)


Drupal.org doesn't accept this license for any code in its repo.  For code to be permitted in the repo, it must be licensed under: "version 2 of the [GPL] License, or (at your option) any later version".  There are no exceptions to this rule.

Provided you can get the license right, there is nothing in the Drupal.org Git Repo Policy that prohibits a bridge module that requires other software (i.e. not packaged on Drupal.org) to be hosted on Drupal.org.


  For that matter, since Git is so horrible with submodules, I wonder if the Drupal repository can even handle submodules.


When a bridge module is hosted on Drupal.org (and there are plenty of them there already), it has to be combined with other required bits and pieces manually (i.e. there must be human readable instructions in the README about where to find the other software and how to assemble the pieces).  While I can see the beauty of using Git to pull all the pieces together, that is not how it is done.  Provided you and your users can deal with a two phase install where a human is required to do the assembly, it is doable.

As noted by Alfred Armstrong in a comment, the convention is to have a directory below the libraries folder (usually sites/all/libraries) to hold files the user must download from elsewhere. Then use the Libraries API module to integrate the bridge with the other files.