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
I think your first roadblock would be the .info files - the .info needs to be called 'modulename.info', and you won't be able to enable it if it's not syntactically correct for your version of Drupal. However, it would be quite possible to release a module package with both a D6 and D7 module. Then these could share include files if necessary. That is, you could probably release a folder structure / package along the lines of: mymodule/ includes/shared.inc mymodule_d6.module mymodule_d6.info mymodule_d7.module mymodule_d7.info Where 'includes/shared.inc' would include logic shared between the two different modules. Both modules would show up on the 'Modules' page, but only the one corresponding to the correct version of Drupal could be enabled. Brian Vuyk Web Design & Development http://www.brianvuyk.com 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
If folks start doing a lot of that, might be nice to add support for an 'ignore-if-not-supported' property or something to the .info file so it doesn't show up w/ a warning in the other version. Brian Vuyk wrote:
That is, you could probably release a folder structure / package along the lines of:
mymodule/ includes/shared.inc mymodule_d6.module mymodule_d6.info mymodule_d7.module mymodule_d7.info
Where 'includes/shared.inc' would include logic shared between the two different modules. Both modules would show up on the 'Modules' page, but only the one corresponding to the correct version of Drupal could be enabled. -- Aaron Winborn
Advomatic, LLC http://advomatic.com/ Drupal Multimedia available now! http://www.packtpub.com/create-multimedia-website-with-drupal/book My blog: http://aaronwinborn.com/
+1 - I like that idea. However, I don't see it gaining much traction since the 'proper' way to do it is to roll a release for each version of core. Also, I think the strategy I outlined below is quite messy, and probably shouldn't be used unless there were extenuating circumstance which required you to include several versions of the same module compatible with different versions of core within the same download. Brian Aaron Winborn wrote:
If folks start doing a lot of that, might be nice to add support for an 'ignore-if-not-supported' property or something to the .info file so it doesn't show up w/ a warning in the other version.
Brian Vuyk wrote:
That is, you could probably release a folder structure / package along the lines of:
mymodule/ includes/shared.inc mymodule_d6.module mymodule_d6.info mymodule_d7.module mymodule_d7.info
Where 'includes/shared.inc' would include logic shared between the two different modules. Both modules would show up on the 'Modules' page, but only the one corresponding to the correct version of Drupal could be enabled.
I certainly hope they don't do it a lot. As of Drupal 6, info files must specify their core version and will be rejected by any other core version. If you have code that doesn't change between two versions, sure, you can put it into an include file of your own. And then look into a good source code management system. (Where good = not CVS. It looks like Drupal.org has finally started the process of moving toward git, which should make such code management substantially easier.) Really, this is exactly where good branch and merge management is your friend. There's no reason at all to ship "dud" D6 code with a D7 module or "dud" D7 code with a D6 module. --Larry Garfield Aaron Winborn wrote:
If folks start doing a lot of that, might be nice to add support for an 'ignore-if-not-supported' property or something to the .info file so it doesn't show up w/ a warning in the other version.
Brian Vuyk wrote:
That is, you could probably release a folder structure / package along the lines of:
mymodule/ includes/shared.inc mymodule_d6.module mymodule_d6.info mymodule_d7.module mymodule_d7.info
Where 'includes/shared.inc' would include logic shared between the two different modules. Both modules would show up on the 'Modules' page, but only the one corresponding to the correct version of Drupal could be enabled.
Larry, A bit of clarification:
I certainly hope they don't do it a lot. As of Drupal 6, info files must specify their core version and will be rejected by any other core version.
The problem here is that just as the Drupal project won't bundle certain things due to licensing issues, some other projects can't (or won't) put themselves under the Drupal repository. The CiviCRM project is an example. It uses an Affero license, and it can be deployed under Joomla, as a standalone, or under Drupal. For other projects, it can be difficult to link themselves to the hip of the Drupal release schedule. Their user base likely will lag in D7 adoption, for mostly sociological reasons (they server a lot of small non-profits). But there are definitely users that need and want to use D7 for other reasons. The CiviCRM project, while it has a growing community, is much smaller than the Drupal community, and it's difficult for them to support multiple Drupal versions. I don't speak for the CiviCRM people; I'm just a developer that does a good deal with their platform. But I'm aware this is an issue for them. Very reasonably, I think. I'm hoping that it's possible to put two .info files referring to different module names, each .info referring to a different Core version. If by "reject" you mean ignore (rather than, say, go ape s***, white screen or otherwise misbehave, this is excellent, since both modules can be packaged with the larger project, and Drupal will just choose the "right" module. Rob
Aaron Winborn wrote:
If folks start doing a lot of that, might be nice to add support for an 'ignore-if-not-supported' property or something to the .info file so it doesn't show up w/ a warning in the other version.
Brian Vuyk wrote:
That is, you could probably release a folder structure / package along the lines of:
mymodule/ includes/shared.inc mymodule_d6.module mymodule_d6.info mymodule_d7.module mymodule_d7.info
Where 'includes/shared.inc' would include logic shared between the two different modules. Both modules would show up on the 'Modules' page, but only the one corresponding to the correct version of Drupal could be enabled.
For a project like CiviCRM, I would definitely encourage them to separate as much code as possible out into "agnostic" libraries that would work under Drupal 6, Drupal 7, or Joomla and just have a compatibility layer for each one that ties into the APIs for that host system. That's a very common approach in systems programming. What I would discourage is shipping a single tarball that contains both the Drupal 6 and Drupal 7 bridge code (and the Joomla bridge code? Why not?). I cannot see a reason to do so; offering a separate download for each is not hard, and with proper source code management maintaining two branches shouldn't be hard either. They already have to to support Drupal and Joomla anyway. I'm certainly not discouraging Civi or anyone else from maintaining a Drupal 6 version of a module after Drupal 7 is released. It's just a matter of how they do so. I do not believe that Mac-style "fat binaries" are the correct approach. --Larry Garfield On Wednesday 17 February 2010 01:26:31 am Rob Thorne wrote:
Larry,
A bit of clarification:
I certainly hope they don't do it a lot. As of Drupal 6, info files must specify their core version and will be rejected by any other core version.
The problem here is that just as the Drupal project won't bundle certain things due to licensing issues, some other projects can't (or won't) put themselves under the Drupal repository.
The CiviCRM project is an example. It uses an Affero license, and it can be deployed under Joomla, as a standalone, or under Drupal. For other projects, it can be difficult to link themselves to the hip of the Drupal release schedule. Their user base likely will lag in D7 adoption, for mostly sociological reasons (they server a lot of small non-profits). But there are definitely users that need and want to use D7 for other reasons. The CiviCRM project, while it has a growing community, is much smaller than the Drupal community, and it's difficult for them to support multiple Drupal versions.
I don't speak for the CiviCRM people; I'm just a developer that does a good deal with their platform. But I'm aware this is an issue for them. Very reasonably, I think.
I'm hoping that it's possible to put two .info files referring to different module names, each .info referring to a different Core version. If by "reject" you mean ignore (rather than, say, go ape s***, white screen or otherwise misbehave, this is excellent, since both modules can be packaged with the larger project, and Drupal will just choose the "right" module.
Rob
While this might be entirely possible, what's the advantage? It's not like you can just swap between D6 and D7 cores and not have problems. You have to go through the proper upgrade path. Since you can't just change versions, I highly recommend using proper source control branching instead of polluting your codebase. - Ken Winters On Feb 16, 2010, at 1:31 PM, 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
Having read the other comments on this. I agree it isn't desireable and probably not that feasible. (I was about to write the same thing). 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 :). 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
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
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
participants (7)
-
Aaron Winborn -
Brian Vuyk -
David Metzler -
Ken Winters -
Larry Garfield -
larry＠garfieldtech.com
-
Rob Thorne