[drupal-devel] release info, introspection and debug
Once upon a time, like around release 4.1 or 4.2, I started coding a module which would enable several debug features, both locally and remotely. One part of that was an XML RPC which could be turned on administratively which would allow a query to return some information about the Drupal installation. The information was intended to be items which would help debugging a problem, providing support or reporting bugs/problems in the software. The module would gather the information and send it as a returned array from the RPC. Unfortunately, I accidentally deleted my work before it got backed up or committed to my local CVS. One of the roadblocks I had at the time was no good way of knowing which versions of the various pieces of the Drupal software were being used. Since then, partly because of my asking for it, all (most?) Drupal files have a $Id$ CVS keyword in them, in a comment line. At a minimum, that would allow an fopen() or similar to be used to find out what versions of files were being used. Not the most beautiful way of handling this issue, but at least workable. Another problem that I was trying to solve then, and that I still run into often now while managing half a dozen or so Drupal-based sites in my so-called spare time is knowing which version of software they are currently running. I can figure this out eventually via one method or another, but it would be so nice to be able to just view it from the admin options. This piece of information would also be useful for the previously mentioned debug/reporting module, too. To that end, is there any chance we could make it convention that all Drupal files would, in addition to the $Id$ keyword, include the $Name$ keyword? And if all that sounds reasonable, I'd like to mention briefly a common coding pattern for handling just this kind of question, and one which I also use in most source files. That is, make these version and release strings available to the program itself without file reading (fopen()) introspection tricks. Extremely common example from C (source code to most Unixes): #if 0 static char sccsid[] = "@(#)w.c 8.4 (Berkeley) 4/16/94"; #endif static const char rcsid[] = "$FreeBSD: src/usr.bin/w/w.c,v 1.38.2.7 2003/08/15 21:58:14 rwatson Exp $"; Similarly, in PHP: $version = "\$Revision: 1.6 $"; $release = "\$Name: build_1_2_19 $"; Any chance of doing something like that with Drupal? If not in all files, maybe just the release in common.inc? -- Chris Johnson
Extremely common example from C (source code to most Unixes):
#if 0 static char sccsid[] = "@(#)w.c 8.4 (Berkeley) 4/16/94"; #endif static const char rcsid[] = "$FreeBSD: src/usr.bin/w/w.c,v 1.38.2.7 2003/08/15 21:58:14 rwatson Exp $";
Similarly, in PHP: $version = "\$Revision: 1.6 $"; $release = "\$Name: build_1_2_19 $";
Any chance of doing something like that with Drupal? If not in all files, maybe just the release in common.inc?
Wuh, using these kind of variables are evil. I suggested back then to use the _help hook with the '#version' (or something alike) $section to grab the version, so this should work: function somemodule_help($section) { switch($section) { case '#version': return '$Revision: 1.6 $'; } } Similarly for $Name if you need it. Goba
Wuh, using these kind of variables are evil. I suggested back then to use the _help hook with the '#version' (or something alike) $section to grab the version, so this should work:
function somemodule_help($section) { switch($section) { case '#version': return '$Revision: 1.6 $';
And this will be done by CVS I hope? Similar to what CVS does now: // $Id: textile.module,v 1.14.2.1 2004/09/23 15:45:55 jhriggs Exp $ ? Bèr [ Bèr Kessels | Drupal services www.webschuur.com ]
Wuh, using these kind of variables are evil. I suggested back then to use the _help hook with the '#version' (or something alike) $section to grab the version, so this should work:
function somemodule_help($section) { switch($section) { case '#version': return '$Revision: 1.6 $';
And this will be done by CVS I hope? Similar to what CVS does now: // $Id: textile.module,v 1.14.2.1 2004/09/23 15:45:55 jhriggs Exp $ ?
Yes, the intention is that CVS will replace it. We could also have some wrapper function used right there, so that real version numbers (erm, actually strings) are returned: return drupal_parse_revision('$Revision: 1.6 $'); And so function drupal_parse_revision($string) { $parts = explode(" ", $string); return $parts[1]; } Goba
Gabor Hojtsy wrote:
Wuh, using these kind of variables are evil. I suggested back then to use the _help hook with the '#version' (or something alike) $section to grab the version, so this should work:
function somemodule_help($section) { switch($section) { case '#version': return '$Revision: 1.6 $'; } }
Similarly for $Name if you need it.
This solution works fine for modules. I did not mean to say we had to have variables exactly like that, but rather just wanted some programmatic way to retrieve the CVS expanded keyword. Then I can write a module or an XML RPC that will return a summary of module versions installed in a particular site, for example. I still would like to have a way to find out which version of common.inc or cron.php is in use, though. Any suggestions? If we agree that such a facility in Drupal is desirable, and agree on a method for providing it, I'm willing to do all the work of modifying all existing modules and/or files to implement it. If this is viewed as too much software bloat, then I would request that a comment line after the existing // $Id$ line be added to include // $Name$ and I will write code to walk the directory tree and examine the files. That way the resource cost is paid only at execution time when requesting that data. -- Chris Johnson
Any further thoughts on this? Should I just go ahead and create an issue, and a patch? I kind of don't want to do all the work if there is close to zero chance of it getting accepted. -- Chris Johnson
participants (3)
-
Bèr Kessels -
Chris Johnson -
Gabor Hojtsy