provide an API to detect the drush version

Agreed - we discussed this at #425670-11: drush self update ... Lets use DRUSH_VERSION constant.

If you want to avoid side effects, maybe it should be stored in a non-php file.

version.txt:

DRUSH_VERSION = 2.1

or:

version.txt:

2.1

Or perhaps even:

drush.info:

name = drush
version = "2.1"

A module .info file would have version = 7.x-2.1 or something like that; I'm not sure what the format would be for drush, which is independent of the Drupal version.

a constant in drush.inc looks good to me ... I think it should currently read 3.0-dev, for better consistency with drupal's system.module pattern.

I didn't see your patch -- I was typing.

A .inc file does have a side effect of sorts; if you include one more than once, you will get a 'function already defined error' for the defined functions in the file. require_once will help, but won't save you if two different .inc files include the same function.

Suppose you're trying to do a drush self update, and you want to know what version the to-be-installed package is. If you want to always trust the uri / filename, then you're good with drush.inc. If you want to be able to unpack the target and verify its version, then a .txt or .info file is better.

I could quite easily agree that it's fine to trust the filename, but there's one more thing to discuss before committing the patch as submitted, and that is how to version HEAD. It seems that define('DRUSH_VERSION', '2.1'); should only appear in a stable tagged release of drush. drush-HEAD should instead have something like define('DRUSH_VERSION', '3.x-HEAD');.

I'm not exactly sure if 3.x-HEAD is correct, but in any event, whatever is committed for HEAD should be appropriate for HEAD, naturally.

There I go typing again.

+1 for the patch in #3 with the text "3.0-dev".

How about this.

I used the same format as a .info file to store the version, but I named the file "drush.txt" instead of "drush.info" to avoid the risk that some code might confuse drush with a drupal module. (Edit: I notice from #425670: drush self update that "drush.info" is going to be created when drupal.org packages up drush, so that filename is definitely out.) I'm not sure that "drush.txt" is the best name; any better suggestions? "drush.version" might be nice, although eventually other stuff could go in this file.

My comments on my opinions on what the version should be are in #682644: Provide a stable release branch, but at the end of the day, I think that the current drush version is whatever Moshe says it is, so I put in "3.0-dev" per #6 above (which is pretty much what I would pick anyway).

I agree, and in fact, this morning it struck me that "drush.info" is the right filename to use. This file should be checked into cvs with the current "dev" version. When someone makes a cvs tag to create a release, the Drupal packaging system will overwrite drush.info with a file that will contain the right version number.

At least, that's what I thought would happen; the current 2.1 tarball does not contain a drush.info file. I still think that drush.info is the way to go, but if anyone can shed any light on the packaging system (which I've read a little about, but have never used), I'd appreciate it.

Here's a better patch.

Maybe the .info file doesn't get created if it already exists?

I'm thinking the opposite; since there is no .info file in 2.1, and there is no .info file in the current 2.1 tarball...

Your suggestions look good to me, but since I have no practical experience with packaging, I must defer to others judgement in this matter.

Lets add version info to status command and not do own command for this. When we need to get version info out programmatically, we can add a --pipe option for status. Otherwise, looks good.

How about drush status foo as an equivalent for drush status | grep '^foo' | sed -e 's/^foo://'? (That's approximate, not tested / working). I know you usually don't want to add overhead to drush where grep will suffice, but it seems that the utility would be high enough in this instance to make it worthwhile. More and more stuff is getting accumulated in status...

Hmm. Maybe. This is a bit like wanting to control the columns that get emitted as we have discussed for statusmodules.

In this case, I think a --pipe which emits CSV or .ini or something is a bit more consistent.

Here is a patch with "Drush Version" included in status. Status will now print the drush version instead of the error message if it cannot find a valid drupal installation. An "ini-file-like" output is produced with "drush --pipe status".

The "drush version" command is gone. Must say I was mighty partial to it, though. Oh well.

alias dv="./drush status --pipe | grep 'drush_version' | sed -e 's/.*=//'"

:)

OK, I just re-read your suggestion from #17. I like it too. Lets add it. You could rip out the new --pipe stuff if you think its not needed anymore.

I guess drush.txt is for me to author. OK, I can handle that. Will just put version in there for now.

No, it should be drush.info -- and I just forgot to cvs add it, so it didn't show up in the diff. I'll do the addition from #17, cvs add drush.info and then post a new patch.

I think I'll leave the --pipe stuff there, unless someone wants me to get rid of it.

Okay, here it is again, this time with drush.info included.

$drush status version
  Drush Version     : 3.0-dev
  Drupal Version    : 6.14
$drush status drush-version
  Drush Version     : 3.0-dev

I think that --pipe is still very useful, so I left it in.

I thought we were going to provide a way to get just the value without the label. So, one of these should return only 3.0-dev:

$drush status drush-version
$drush status drush-version --pipe

No problem at all. Here you go.

OK, very close. Sorry to keep nitpicking this ...

- document --pipe option in command help. perhaps in 'examples' as well
- move drush version and php config to the end of the since those are likely not what the user is after.
- is there some reason we don't use drush_print_table() instead of these aligned colons? I think long values would wrap better. I asked similar question at http://drupal.org/node/679832#comment-2468256 but got a slightly unsatisfying reply. I know that this issue isn't about presentation, but while we're here ...

Edit: Stuff an nonsense; the italics below make no sense. Skip that part.

I'm going to echo the slightly unsatisfying reply again here; it is a pain to make an array of the kind that drush_print_table wants. drush status is providing an array of key : value pairs, but drush_print_table wants an array of rows containing an array of columns. Awkward. Rather than try to adjust the array prior to processing, I "fixed" drush_print_table so that it could also accept an array of key : value pairs, which it interprets as a two-column table. This is okay, but I think I like the aligned colons better, both from an output and coding standards viewpoint.

I added the documentation and reordered the output as suggested; I also switched the output from cvs to space-delimited to match what 'help' does. (Similarly, I did not document --pipe in 'options' because 'help' does not do this, and --pipe is already documented in the global options). However, I must say that I remain in doubt about the values-only output format. drush status --pipe now reads like some sort of obscure Jeopardy question; in contrast to drush help --pipe, I cannot imagine how the output of drush status --pipe would ever be used in a script. I think that the ini-format should come back. I toyed briefly with the thought of printing only the value if there is only one item in the output (e.g. drush status drush-version --pipe), or revert to ini-format if there are multiple lines. This would usually be what you wanted, but you could get into trouble if you called drush status --pipe expecting ini-format, but got back only "3.0-dev" because Drupal didn't bootstrap and there were no other values in the table. For this reason I hesitate, but it might still be the best / simplest option.

You can commit this patch if you like it, but I am ready to roll another version to adjust some of this stuff if you want. Take a look, see how it feels and let me know what you think.

Here is a new patch that uses drush_print_table via a better construct that still preserves the useful key : value format of the status table array. I still like the aligned colons better, but this at least removes the bad taste from patch G.

I also modified drush status --pipe to print either a single value or an ini-format list depending on the size of the result set. This is almost always just what you want, but perhaps it is a bit too magical.

Try it on and see how it feels. I'll roll a hybrid of H and G if you like, or something different.

I like using drush_print_table because of its superior wrapping of long values. I added a long Lorem ipsum to the end of our new drush version value and it wrapped perfectly.

I'm fine with committing this as is. If you prefer the colons, then I have a proposal; rewrite drush_key_value_to_array_table() as a wrapper around drush_print_table(). In the new wrapper function, prepend a colon to each value.

about presentation and my unsatisfying response: a few days later I propose a new function `drush_sprint` with signature drush_sprint($key, $value, $indent = 2, $width = 18, $separator = ": ").

Basicly $output .= drush_sprint($key, $value); do the same as `drush status`'s old way $output .= sprintf(" %-18s: %s\n", $key, $value);. It also does custom wrapping (no php function) that has worked pretty well in my tests.

Patch and the resulting output at 80 columns at #679832-7: pm-info: show info for one or more projects.

If you prepend a ':', then the lines won't wrap right. Inserting an extra column between the key and the value (containing a ':', of course) solved the problem perfectly, though.

Committed. Please go ahead and re-open if the behavior of --pipe bugs you.

(The solution is always out there.)

I hadn't thought of adding a column. Nice one.

--pipe behavior makes sense to me. i think we should add another help example that does `drush st drush_version --pipe` so folks know they can get a raw value.

Committed. Also fixed the help text that was incorrect (still applied to patch in #27).