[development] Distributing "bi-modal" Drupal modules

[David Metzler]

Joomla core developer?  I don't know whether to be flattered or  
insulted....

I'd argue that they are no harder to cope with than the solution that  
your proposing here, especially if they try to install a single other  
module into their drupal installation, and discover that yours is the  
only module that follows this paradigm.  (Please download the 7.2  
module for your fixes.... yes I know you're running 6.x but that's  
where the code is, trust me.)

I wouldn't have chimed in if I hadn't written a ton of deployment  
scripts and systems.  Really, deployment strategies are best if they  
are as loosely coupled as possible from the code base.  IMHO, if  
you're going to start asking about how to make this work and it  
conflicts with the dependency management system in drupal, you're  
barkin up the wrong tree.  This will be the first thing that breaks  
as you say in drupal api revisions.  You're still going to have to  
write code that instrospects drupal to figure out what version it is  
and then load different code based on this.  This is seriously going  
to obfuscate your contrib module, not to mention complicate your  
repository (the version 7.x.4 branch of the 6.x.3 module etc. )

I really do believe what your talking about will be harder to  
implement than a drupal specific packaging script over the long haul,  
or I wouldn't have chimed in.

Just to set the record straight.... I'm a contrib developer, not a  
core developer and deal with the api changes all the time.

Dave



36 PM, Rob Thorne wrote:

> David Metzler wrote:
>> I think this would be best solved with install scripts provided  
>> with the external softward product (e.g. CiviRM) .  That is the  
>> third party product comes with both distros of the contrib  
>> module.   That packaging /install script might event be able to  
>> get away with reading the .info files of a core module to  
>> determine the correct version to install, but then would install  
>> the right version based on the detected drupal version.  In fact  
>> I'd be willing to bet that you'd find the install scripts easier  
>> to implement than what you're puposing here :).
>>
> Spoken kinda like a Joomla core person, ironically enough.  Eeek.   
> You know not what you ask.  That's a serious burden on another  
> project, since those kinds of solutions are hard to engineer, and  
> they tend to hard for end users to cope with as well.
>
> Sometimes, it's worth following The Golden Rule when dealing with  
> other developer communities.  While the Drupal community has gotten  
> fairly adept at dealing with breaking compatibility every year or  
> so, it can be make it hard for other projects to deal with us.
>
> The best approach (one that we generally follow with in this  
> project) makes most things self configuring.  I don't think it  
> would be all that hard to accommodate this -- and perhaps we do:  
> I'll have to experiment with Drupal 6 and Drupal 7.  But if we  
> don't, we arguably should.  Not all projects can or will distribute  
> their Drupal modules via Drupal.org, and not all projects will  
> choose to deploy only via Drupal.  We may not need or want to make  
> it all that easy.  But I don't think we need or want to make it  
> harder than it needs to be either.
>
> Rob
>> I agree that even if its possible its not sustainable.
>>
>> I frankly don't think version control systems will solve this  
>> problem for you since you're talking about a distribution problem  
>> and not a code management problem.
>>
>> Dave
>> On Feb 16, 2010, at 10:31 AM, Rob Thorne wrote:
>>
>>> There are a couple of large software projects that  are designed  
>>> to install together with Drupal (CiviCRM is one of them).   
>>> Typically, a project like this distributes a Drupal module that  
>>> handles the embedding of the project inside of a Drupal install.
>>>
>>> Is it even possible for a project like this to distribute either:
>>>
>>>   1. Both a Drupal 6 *and* a Drupal 7 module (i.e., will Drupal  
>>> look at
>>>      the .info files and ignore the "wrong" version), or
>>>   2. A single Drupal module that keeps its Drupal-version specific
>>>      features (changed, new or dropped API calls, hooks with
>>>      incompatible call signatures, etc.) in .inc files and loads  
>>> them
>>>      dynamically?
>>>
>>> This is not "the done thing", and the module upgrade instructions  
>>> in the handbook show it would be pretty daunting to do for  
>>> anything but a trivial module.    But is it even possible?
>>>
>>> Rob Thorne
>>> Torenware Networks
>>
>