drush self update

maybe we also need a reminder if a new drush version is available whenever we run drush pm update (or its new analog if it has changed ..)?

and in the README we need more detailed description:
- exact and brief tutorial - with the exact sequence of commands and paths
- the initial checkout and the further update commands

we can nearly do self_update today. see `drush pm info drush` and `drush dl drush`. we should still do a dedicated selfupdate command but the pieces are there.

Stages of the self-update done via drush itself:
1. info - drush somehow discovers that it needs update (suggestion: hook it on every dr pm update and refresh)
2. remove old drush (thus moving/removing the very .php file that invokes the remove command - how is this supposed to work? ) , backing it up to a backup folder next to the old drush
3. dl new one and move to old drush's place

Self-update via cvs:
0. info - the same as 1. above
1. go to drush dir (a drush command can do that , yes?)
1.5. optionallty do a backup copy
2. do a cvs checkout with a predefined release tag - we're done

( as long as I know linux file systems when you checkout from cvs and thus change the same file that is invoking the change it will continue working and on next invokation it will be the newest version - I suppose it is the same if the file is removed and recreated) RIGHT?

The best scenario is that we do not care about the dl method - be it wget or cvs...

Thank you a million times for this tip! I couldn't find the drush cvs install instructions anywhere ... I guess I should have guessed it was the same as any other cvs module install! Dohhh! Still getting used to cvs....

"Still getting used to cvs...." - use the 'cvs instructions' tab up on the drush project page. Currently I am using the code there to checkout the new drush code and move it in the place of the old one after diff-ing to see what has changed ...

lol ... wow I did not see that there... damn.
I guess its a habit I almost always go directly to google for everything,
which sometimes is akin to the whole needle in the haystack paradigm.

Cheers!
>_<

Hi, Moshe pointed out this issue to me.

I wrote a "drush version" command. See attached version.drush.inc.

It finds all the drush.inc files ( drush_commandfile_list(); ) and does a cvs status on them. I'm new to programming Drupal and Drush and I'm interested in feedback on the code if you have it.

The result is this:

aegir@vps10326:~/drupal-5.x$ drush version
Name                    Version                 File Path
----                    -------                 ---------
simpletest              DRUPAL-6--2-0-RC1       /var/aegir/drush/commands/simpletest/simpletest.drush.inc
core                    DRUPAL-6--2-0-RC1       /var/aegir/drush/commands/core/core.drush.inc
sql                     DRUPAL-6--2-0-RC1       /var/aegir/drush/commands/sql/sql.drush.inc
pm                      DRUPAL-6--2-0-RC1       /var/aegir/drush/commands/pm/pm.drush.inc
provision_mysql         DRUPAL-6--0-2-BETA1     /var/aegir/.drush/provision/db_server/provision_mysql.drush.inc
provision_drupal        DRUPAL-6--0-2-BETA1     /var/aegir/.drush/provision/platform/provision_drupal.drush.inc
provision_dns           DRUPAL-6--0-2-BETA1     /var/aegir/.drush/provision/dns_server/provision_dns.drush.inc
provision_apache        DRUPAL-6--0-2-BETA1     /var/aegir/.drush/provision/web_server/provision_apache.drush.inc
provision               DRUPAL-6--0-2-BETA1     /var/aegir/.drush/provision/provision.drush.inc
version                 Unknown.                /var/aegir/.drush/version.drush.inc
hosting_client          DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/client/hosting_client.drush.inc
hosting_alias           DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/alias/hosting_alias.drush.inc
hosting_migrate         DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/migrate/hosting_migrate.drush.inc
hosting_db_server       DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/db_server/hosting_db_server.drush.inc
hosting_site            DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/site/hosting_site.drush.inc
hosting_platform        DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/platform/hosting_platform.drush.inc
hosting_web_server      DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/web_server/hosting_web_server.drush.inc
hosting_package         DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/package/hosting_package.drush.inc
hosting                 DRUPAL-5--0-2-BETA1     profiles/hostmaster/modules/hosting/hosting.drush.inc

I'm new to Drush, but was trying to get Aegir installed and ran into some trouble setting up Drush. This was very helpful in figuring out what, was what version, and where.

I hope you find it useful!

Duplicate bug: http://drupal.org/node/462978

@michaelcole - perhaps merge this info with statusmodules command.

self-update ought to be its own command.

one missing piece is that drush does not know its own version. If one uses a tarball from drupal.org, we can discern the release from drush.info but otherwise no. I think we need to add a DRUSH_VERSION constant like drupal core and keep bumping that with every release.

@11: totally agree - DO IT

DRUSH_VERSION patch suggestion in #683942: provide an API to detect the drush version, this here is about updating drush.

Owen would likely review any patches that show up here. This is quite related to project update code.

Subscribing. (I was thinking about opening an issue about drush self update notification when I found this.)

we added that VERSION constant but not much else related to this issue? Any thoughts on how to implement this?

This would be really useful feature.

sub

I'm posting this here as it seems everything related to handling drush versions is duped against this issue. I'm happy to open a new issue if it is needed. The attached patch adds support for "drush version" and "drush ver". It simply runs drush_print(DRUSH_VERSION); The simple things in life are often the best :)

As documented in its Examples, try: drush status drush-version --pipe

The syntax is verbose, but it works. It would be good if this was documented in the README or somewhere else a bit more obvious. Should I submit a patch for that?

OT: It seems that this doesn't work with the Debian packages as the .info file is dropped in packaging. I will open a bug report in Debian so anarcat can look at it. http://packages.debian.org/sid/all/drush/filelist

woops. didn't mean to change status.

if we document every trick like this in the readme, it gets to be book length. everyone needs something different and everyone wants the doc to be "somewhere else a bit more obvious". all the obvious seats are taken.

subscribing

Lets get back to selfupdate. Anyone have thoughts on what we should do here? We are starting a push for Drush4 and it would be great to get this in

subscribing

Hi all, it looks like checking only for the DRUSH_VERSION constant may not be enough, when you need to monitor changes to the HEAD snapshot?

Just an idea: One possible approach would be to also use the variable "datestamp" added by the drupal.org packaging script, as if it was the version suffix. To self check for update status, Drush could compute the version string as the result of concatenating the DRUSH_VERSION constant and the .info variable "datestamp".

First stab attached.

This basically works, but needs some improvements in version handling -- should upgrade from dev to dev if on a dev branch, should match version_major, etc.

Maybe late for drush-4, but marking for the drush-4 release queue anyway. (Edit: Oh yeah, it's a feature request, and therefore not in the queue anyway.)

Hmm. I'm OK with hooking into updatecode. Other possibilities which are equally fine for me:

- Add new selfpdate command
- Add new version command which prints out current version and checks for upgrade by default. one could disable the upgrade check with an option.

It is non ideal to require a date in .the info file. Lets fall back to drush_version if date is unavailable. But that does not work for HEAD => HEAD. Hmm. Maybe issue a git pull in this case? As you can see, I am not too clear on all this. Maybe jonhattan has some input.

I'm up for adding this to Drush4

My thought is that drush status and drush pm-updatecode could write drush_installed_date to the .info file if there is no datestamp there. Then you might miss one release, but eventually you'd be good again.

Could the version command be both drush version and drush --version? I'd be up for that. I recommend keeping it in updatecode, so it's somewhere that will get hit even if you don't think to check it.

Unfortunately, I don't think we can default to a version check during updatecode. has to be opt-in if it is in a popular command like updatecode.

I'm confused by the point you're trying to make in #30. I agree that there should be an 'are you sure', with an option to skip the warning altogether in updatecode. I was suggesting using it in both updatecode and in the version command -- with both commands supporting the same disable option.

Sorry i was unclear. I don't add a new network request to updatecode by default. We should check drush only if the user requests it. Thats the only point I am making.

If we don't do the check in updatecode, then we can enable a check by default in a new version or selfupdate commands. Adding --version to `drush` makes sense too.

Here is a patch that I think is pretty close.

New versions are detected by comparing with datestamp in drush.info. If there is no datestamp in the info file, then drush will write the current date into drush-installed-date in the info file (first time only), and then use that value thereafter to check for new versions.

You can manually check for drush updates via `drush self-update`, and by default will also automatically check for drush updates after `drush version` (or `drush --version`) and `drush pm-updatecode`. I'm sorry, I realize that's the opposite of what you recommended, but it only makes sense that usually people are running pm-updatecode because they don't know what updates are available, and it seems that it's worth it to default to telling people when there's a new drush release, even if that takes a bit longer. Some won't realize that drush has this feature, so I think it's better to default to on. It's easy to turn off (instructions on setting $options['self-update'] in examples.drushrc.php) if you get tired of the lag. If you feel really strongly that it should default to off, it would be easy enough to change the code to do it that way.

Also, the code will usually only offer updates to the latest stable release. You can check for the latest dev release via `drush self-update --dev` or `drush self-update --head`, or by setting $options['self-update'] = 'head'; in your drushrc.php.

Finally, self-update is hooked into pm-download. If you say `drush dl drush --select`, then you can pick your version of drush and choose to have it installed either in the default location (cwd) or use it to replace the currently installed version of drush.

My only self-criticism at this point is that the fact that drush modifies drush.info on the fly means that maintainers might accidentally check this file in or include it in a .patch file. Maybe I should write this value into a different file (e.g. put datestamp=... into drush-installed-date.info, or something like that). Not sure what's best here.

Yeah, getting closer.

What if we change the updatecode and version (or all commands?) so that they nag instead of perform a network request. The model I am thinking of is that of macports (and presumably other package managers). They warn 'You have not run self-update for 2 weeks'. In order to achieve this, drush needs a writable place to store the last selfupdate time. How do package managers store this? Do they use a hidden file in the curren't user's $HOME dir?

It is true that we would be nagging even when there is nothing to do. Needs some more thought. The benefit is that updatecode would not get random;y slow once in a while.

I timed it, and when drush is up-to-date, `drush self-update` took 0.55s, and `drush @site self-update` took 0.62s. Your times may vary, of course, but I don't think that's enough of a delay to cause me to want to make `drush pm-updatecode` default to not checking drush. After all, pm-updatecode is already checking to see if N projects have code updates, and N may vary from site to site; drush is just making it N + 1. The nagging would be more trouble than it was worth. Users who wanted to run pm-updatecode aggressively (e.g. every hour in cron) and did not want to update drush could turn off the test in their drushrc.php.

This patch is the same as #33, save for the fact that it stores the install date in .drush-cache.info instead of drush.info. Putting it in $HOME/.drush or some similar location would run the risk that the install date might become meaningless if another version of drush was installed. Storing it in the drush install dir insures that it will be automatically removed if drush is re-installed.

That makes some sense. I'd love for opinions from other maintainers and users.

I think a fair number of users will not have write access to drush. What if we use the $HOME dir and also store the path/to/drush so that we avoid the case you mention where our cache becomes meaningless due to a second drush appearing. Doesn't fix your case of drush getting re-installed.

1. Typo: druch
2. Lets add a command alias of 'selfupdate' (no dash)
3. Deeper updatecode integration
   1. It looks like we move the current drush out of the way and then fetch a new one. Seems risky. We should move at the last possible second just in case the fetch of the new drush fails. If there is a way to use our backup engine stuff that would be ideal.
   2. It would be ideal to integrate release notes here but if it is easier, we can just mention the rln command that they might choose to run for more info.
   3. --lock would be intuitive for folks who want to skip this check. not sure if it is in addition to the drushrc check you already have.
4. Lets not hijack --version for every command. We should limit it to just 'help' or just not offer this feature. It is kinda obscure. If we ditch it, then we use $command_specific in example.drushrc.php
5. We could tell people what version they have when we offer an upgrade (based on drush_version in drush.info).

If users do not have write access to drush, then self-update is disabled and we do not need the install date. Storing the path to drush won't help us save the info in $HOME, because users who hand-update will usually put drush in the same place. I think this situation is too complex to fix; the current implementation behaves pretty well.

3.1. The current drush is moved out of the way after the new one is fetched.
3.3. That would be consistent.
4. --version is consistent with the behavior of most gnu commands.
5. It used to do this. I wonder what happened. :p

Another patch will be coming.

My favorite is .drush-cache.info in DRUSH_BASE_PATH. drush_bootstrap_drush_validate() is a good place to create this file, and the datestamp will be very near to the real install date --it is written before the very first bootstrap. If the file can't be written, drush can't be selfupdated.

Shifting to a wider approach: I've think of pm-updatedrush (in the lack of a better name) to update drush itself and also pure drush extensions as drush_extras, _make, etc. The idea is to have a command similar to updatecode, with a sort of update.module (there's a lot of code for this in pm.drush.inc), --package-handler and --version-control aware. drush is the core and things in ~/.drush and the other available places, the projects. I've some code written for this but nothing to show still. I will work on this tomorrow. Greg: feel free to continue with selfupdate. Mine is just a proof of concept at present.

Those sound like good ideas. drupal-7.0-rc2 was released today, so we have perhaps another 7~10 days at least before 7.0-stable. I'll hold off until I see your patch before I work on this further.

Here is a patch that injects drush and pure drush projects (drush_extras, ...) into the update service, so pm-updatecode is aware of them. It relies on .info files (drush_make and others currently don't have one). git or cvs checkouts are the very same problem we have for module/theme projects,.. I think we can consider adding code from cvs_deploy in drush (cvs_deploy+git_deploy ~ 450 lines).

I've succesfully updated drush and drush_extras. The routine for drush_extras is the same as for any standard project. For drush itself the pm-download approach from #35 is used but it would be better to do it in _pm_update_drush() in a similar way to _pm_update_core().

Perhaps I'm disrupting the issue. I don't know if you prefer this new approach or continue with self-update. In any case I leave it up in your hands till my timezone's tomorrow.

Update status information on all installed and enabled Drupal projects:
 Name                             Installed version  Proposed version      Status                                   
 Administration menu              6.x-1.6            6.x-1.6               Up to date                                                  
 Drupal core                      6.19               6.19                  Up to date                               
 Coder                            6.x-2.0-beta1      6.x-2.0-beta1         Up to date                                       
 Zen                              6.x-2.x-dev        6.x-2.x-dev           Up to date                               
 drush                            6.x-4.0-rc3        All-versions-4.0-rc3  Update available                         
 Drush extras                     6.x-3.0            6.x-3.0               Up to date                               
 Environment                      6.x-1.x-dev        6.x-1.x-dev           Up to date  

^^note the installed and proposed versions for drush. Haven't looked at this further.

I would say that we should keep going as you suggest with a _pm_update_drush(). I am OK with either adding cvs_deploy/git_deploy to drush or with adding drush integration to those modules.

I like _pm_update_drush just as it is implemented now, calling through to pm-download. I think that pm-download should retain its ability to update drush for three reasons. 1. pm-download can update modules. 2. pm-updatecode cannot update from an installed recommended release to a desired dev release, whereas pm-download --dev can, and 3. pm-updatecode does not support the --select flag, and pm-download does. I don' think it would make sense to implement --dev and --select in pm-updatecode. --select would involve too many calls to drush_choice, and as for --dev, would you ever want to update all of your modules to the latest HEAD release? I don't know about that; maybe.

When I tried the above patch, it did find and include drush_extras in the update table, but it did not get the version to update to right. I downloaded drush_extras 3.x-dev via --select, and then tried to update to drush_extras-3.1, which is newer than 3.x-dev (today it is, anyway). pm-updatecode thought that 3.x-dev was up to date. Maybe this is because it is unusual for a stable release to be newer than the dev release; I never bothered to tag dev when I tagged 3.1; perhaps that was a mistake. In any event, when I tried to help drush along via drush pm-updatecode drush_extras-6.x-3.1, it said "Specified version not found", and I could not continue.

Anyway, I like the overall direction, but I don't know a lot about cvs-deploy / git-deploy. Are you interested in continuing this issue? I imagine we're going to want to tag drush-4 shortly.

Oh yes, here's a re-roll of #40 against HEAD. I meant to attach this to #42.

The problem I see with pm-download approach is that we miss the option to update drush via git/cvs (estrictly speaking of update option for those vcs). Also rollback or version-control integration --if ever someone is going to use it.

I'm not having too much time on theese days. I'm in the process of moving and my free time is scarce and scattered so feel free to continue this.

btw, if you're not aware d7 is to be released on 5th january so still there're days to complet this.

I might have time to do something based on #35-#37 in that timeframe. If you don't have time to do #44 before d7, maybe we should consider going back to the simpler technique, so that self update is available in drush-4 (and users could use it to get the better self update when available...)

I'll hold off for the time being -- I have a shortage of free time right now too.

I prefer #40-#43 because it doesn't introduce a new command (that is not to be used on a daily or monthly basis) and also is able to update pure-drush extensions --although they're a few at present.

Some work is needed to review the versions mismatching and also it seems we can easily use cvs/git_deploy api to identify drush version just in case. I think I could work on this before next monday 27th.

For completion: other idea I had in mind (and really is a separate issue) is to provide a drush variant of udpate_info engine (I mean pm/update_info/drush.inc with a lot of code currently present in pm.drush.inc --and also cvs/git deploy). Specifically to update drush without an auxiliary site but also to be able to update anything without update.module enabled.

I agree that #40-#43 is the preferable technique, but we're running down to the wire on the d7 release, and I'm not going to have time to complete w/ this technique.

@jonhattan: are you going to have time to complete this in the next couple of days? If not, should we consider stepping back to #35 - #37 for drush-4, or maybe even just a subset of that so that drush dl drush could be used to do a self update?

Sorry for coming too late. Here is a reroll of #40 with more improvements. Summary of the patch:

1/ new function drush_get_drush_extensions(): create a extension-compatible array for drush_extras, drush_make, drush. Also invoke hook_system_info_alter() to benefit from cvs_deploy / git_deploy.
2/ move drush_get_extensions() from includes/drush.inc to pm.drush.inc. The function now returns modules,themes and the so called drush extensions. So drush extensions participate in drush_get_projects() and all the way with updatecode. --it also expose drush extensions to pm-info and pm-list !
3/ Implement hook_update_projects_alter() to inject drush extensions to update.module so they're first class projects for updatecode.
4/ Greg's code for pm-download from #35.

per 1/ git_deploy is able to detect installed version and we proceed with the update but the update is always done via pm-download, it still needs work to perform a `cvs up`.But I think it can be commited without that for now.

If it's too late for such a big addition to drush I'm fine with the drush dl subset of #35.

Sounds awesome. I'll test this tonight.

To test update of drush, download rc6 and apply the patch. It doesn't work to update head because All-Versions is not a valid supported version.

 [1]   :  6.x-4.0-rc8              -  2011-Jan-03  -  Supported, Recommended 
 [2]   :  All-Versions-HEAD        -  2011-Jan-03  -  Development            
 [3]   :  6.x-4.0-rc7              -  2011-Jan-03  -                         
 [4]   :  6.x-4.0-rc6              -  2011-Jan-01  -     

I've sort of been wondering why drush-3 is "all versions-3-*" and drush-4 is "6.x-4-*". When Drupal 7 is released, and drush-4 goes out to match, will it be 7.x-4 or 6.x-4, and if the former, will that mess up drush self update?

I think it would be okay to 'break' all of the rc's vis-a-vis drush update to go to 7.x-4-* or back to All-versions-4-*.

So, the release title starts out named for the major branch like 6.x-4.0-rc6. Then If I think of it, I replace 6.x with All-versions. If I do that right away, the filename that gets packaged matches with ''All-versions' in the beginning. If not, it doesn't ever get repackaged but I am free to rename the release at any time. The update XML is always right listing the current correct release title and download URL.

I slightly prefer the 'All-versions' prefix over 6.x but not if it is going to cause grief for this issue. It was more important in the drush3 days to communicate that we work for all versions of drupal but hopefully most people know that now.

Still I think drush should stop paying attention to the 'version' element in the XML in favor of version_major and version_patch. See http://updates.drupal.org/release-history/drush/6.x

Will review this shortly.

I looked at the code and it looks like less of a change than what I feared. I'm thinking that is OK to commit. Would be great to get feedback from Greg. I will test a bit as well.

Well, I am completely conflicted on this. Jonhattan has achieved a "grand unification" here by making everything run through updatecode and its rln, version control, locking, etc. Its quite a great accomplishment. I even asked for it in #36.3

I am really bothered though that we require Drupal in order to selfupdate drush. Thats a complete fail, and overwhelms all the other goodness. You might recognize this same objection from my comments about simpletest at #483940: Unit testing library. Maybe for drush5 we will implement our own update_info/update status parser.

So, I am inclined to go with #35-#37 for drush4. If Greg or jonhattan post a new patch like this, then it could go in. If not, we get it early on in drush5 cycle.

I chatted a bit with Owen on IRC and we concluded this together.

I was very excited to be able to see drush_extras in pm-update, and even more excited to see it update successfully. Unfortunately, I had some trouble getting drush to update drush. I didn't track down what was going on clearly enough to report back, but it didn't always work. drush dl drush did work.

In the end, I think I have to agree with Moshe; there isn't enough time to get this in shape for drush4. I'll see if I can re-roll #35 - #37 tonight, and will post a patch if I'm successful. We'll have to wait for drush-5 for the cooler self-update. With the idea in #46 implemented, we could update drush in pm-update w/out Drupal, and that would be cool.

Edit: Rewrote to clarify my earlier comments.

Okay, here is a new patch. This is #35, re-rolled against HEAD with some adjustments per #36.

2. 'selfupdate' added as an alias
3.1. Yes, drush is moved out of the way at the last moment, so there is no problem on failure.
3.2. rln integration not done.
3.3. --lock integration not done.
4. drush --version still prints the version, but if there is any command arg, then --version does not change the command, but instead is passed through.
5. The current version of drush is displayed more consistently now.

pm-releasenotes cannot parse "All-versions-4.0-rc8", so I recommend going with #56 w/out --notes or --lock.

Adding --notes support would otherwise be trivial. "All_versions" might work, so that's a potential workaround. I think I'd still recommend committing, and add the --notes feature in 4.1.

If we are going to move on pm-updatecode direction in a near future I'll wait until then to implement --lock. Doesn't make sense to self-update if you wanted to lock, mm perhaps it does in a multiuser setup.

Also I think something will change for release nodes when drupal moves to git and perhaps we can acommodate our versions better than now.

@Greg note there're a lot of extra whitespaces and tabs in your patch.

Thanks for testing. I'll fix the whitespace when I commit. Waiting for confirmation from moshe before committing.

1. We should add --pipe support to drush_core_version(). Should print version without label.
2. 'drush dl drush --dev'. We need some good docs about why we sometimes recommend selfupdate and sometimes pm-download. Seems to me that we should remove the Example from pm-download help
3. As jonhattan said, tabs are off in pm.drush.inc.

4. file_put_contents($path, $content);
   +  return TRUE;

   . Lets not assume the file_put_contents() succeeds.

1. Better text: "Would you instead like to backup your current drush to XXX and replace with this one?". Also, should we use .drush-backups here?
2. should we add the word 'version' to the output for version command. i see that git does this:
   

   ~/tmp$ git --version
   git version 1.7.2.3
   

   A minor point for sure.

3. Need an error msg when drush is not writable and user explicitly requested an selfupdate (not a silent updatecode check).
4. selfupdate refuses to update from dev snapshot to dev snapshot. it says 'drush 4.0-dev is already up-to-date.' this is confusing IMO.

Okay, this should do it.

Printing the backup directory was trickier than it first seemed it would be. drush self-update does the update operation by calling pm-download via backend invoke, so any context that is set is reset. Passing the backup directory via --backup-dir does not work, because --backup-dir indicates the directory that the backup directory should be created in. To get around this, I added a --backup-location option, which takes the full path to the actual backup directory. Since this is just an internally-used option, I did not document it anywhere in the help text. Seemed like it would be too confusing to have both --backup-dir and --backup-location as documented options.

I got rid of the write_ini_file function altogether in favor of using the mod date of the drush.info file as the installation date in cases where the release date is not available.

Regarding updating drush from a dev release to the latest HEAD, I changed self-update to do that automatically; however, drush -version and drush pm-updatecode will only prompt the user to update drush if a new stable release (or alpha / beta / rc) is published. It didn't seem like a good idea to encourage people to follow _every_single_dev_release_; every now-and-rarely, someone commits a bug to HEAD. The impact of this is less when people are grabbing new dev releases as they want them, as opposed to automatically getting every one.

Other items corrected per #60 and #61.

1. that drush_reset_error() call looks a bit scary as it wipes whatever happenned previously. Consider a drush command that does lots of stuff. It runs for all calls to updatecode. Is there any way to avoid it? lets discuss in IRC.
2. --pipe docs missing on version command
3. missing verb - "'Failed to drush directory "
4. "only stable releases are considered (unless the --dev flag is specified)." I think I dislike that --dev exception. I think a --dev in updatecode doesn't really mean the user wants to update to drush HEAD. I think we only offer to update to a dev snapshot via self-update.
5. I thought of one more wrinkle. We need to disable selfupdate system for drupal 5 sites since we don't plan to support them for drush5.
6. typo: newerv

1. If you run selfupdate and are already up to date, we should do an 'ok' log message saying 'Drush is up to date' or somesuch. Also, even pm-updatecode --debug gives no indication that we tried to update drush. Should see some debug log in there.
2. Our affinity for date based directories under .drush-backups is a bit annoying. would be good to use more descriptive directory names at top levels like site name, project_name, etc. just mentioning it. not for this patch.
3. drush dl drush is still possible and it offers to update the running drush. Should we do anything about that? I dunno.

Committed http://drupal.org/cvs?commit=474728

drush_reset_error removed; it was not actually necessary any more.

--pipe docs added to version command.

--dev is allowed on self-update and pm-download, but not on implicit drush update checks in the --version and pm-updatecode commands.

Drupal 5 case not handled yet; has some tricky implications.

Put in some log messages. The 'up to date' message is 'ok' if called from self-update, or 'notice' if called from pm-updatecode.

Nothing done about date-based directories yet.

drush dl drush is still possible, mainly to allow drush dl drush --select. I think this is okay; pm-download and pm-updatecode behave similarly, so I think it's okay for dl to still do a self-update when invoked directly. It would be easy enough to disable if we decide it's not the right thing, though.

I really think that we should only nag during an implicit selfupdate. The nag message should tell people to do one of

1. Use selfupdate to update drush
2. Manually update drush (perhaos we need not mention this?)
3. Add $options['self-update'] = FALSE to drushrc.php to disable this nag message. The self-update command will still work.

If we go this way, a few lines at top of drush_pm_updatecode() can be removed.

Open to input from others.

Updating drush during pm-updatecode is problematic, because the current version of pm-updatecode will continue to run after an upgrade; for this reason, I exit pm-updatecode after a self-update. Scaling back this behavior to only inform the user that they should run self-update would simplify things; I am in favor. If there are no conflicting opinions, I'll roll a patch later.

Right after posting this I got burned by passing --yes to updatecode. My drush got updated behind my back. And amazingly, updatecode continued as always, while drush code got replaced behind its back.

Assigning to Greg.

Whoops, that's a bug -- and you're right, people are going to pass --yes to pm-updatecode, and this must not update drush. Should have thought of that.

This patch removes the capability to do a drush self-update from upc. I do not think that drush upc --yes should ever upgrade drush; when we return to jonhattan's work with updating drush extensions, I think that we shouldn't add drush to the list of modules in upc; only drush_extras, drush_make, etc.

Anyway, getting back to the patch at hand, upc now will only nag if there is an update available. The nag message instructs how to update drush ('drush self-update'), but it does not advertise how to remove the nag message. Help on doing that appears in examples/example.drushrc.php.

I think we need to advertise $option['self-update'] = FALSE in the nag message and/or in the doxygen for updatecode. just trying to be considerate of folks who take a long time to update. they might not need our shiny new code.

Code looks good otherwise. feel free to commit with that change.

Committed.

I am running drush head from a cvs checkout (i.e. does not have timestamp info). I go into a D6 site and do a selfupdate (or updatecode) and drush gives me a rather unreasonable recommendation to downgrade to latest stable:

~/htd/d6$  drush selfupdate -d
Found command: self-update (commandfile=core) [0.13 sec, 6.89 MB]    [bootstrap]
Downloading release history from                                        [notice]
http://updates.drupal.org/release-history/drush/7.x [0.14 sec, 6.91
MB]
A newer version of drush, All-versions-4.0, is available.  Would you like to back up your current drush, version 5.0-dev, to /Users/mw/.drush-backups/20110110203552 and replace it with the newer release? (y/n): n
Command dispatch complete [12.99 sec, 6.9 MB]                           [notice]

Whats the best way to avoid this case?

Well miff; that was a design flaw. At the last minute, I switched from using a cache file to just checking the mod date of the drush.info file. That scarcely matters, though, as in either of those two cases, the date returned will not be accurate if drush was checked out from CVS, as a CVS update will pull in a new version of drush without changing the datestamp of your drush.info or the datestamp in the cache (depending on implementation).

Fixing this would involve calling cvs commands, so instead I opted for the simpler solution of just disabling self update when drush is checked out from CVS. Those who use CVS checkouts can just cvs update -AdP to find out if there is a new HEAD. With this patch, there must be a datestamp in drush.info in order to use self-update.

Committed. Thanks.

I added drush_log($error, 'notice') so we can see these errors if needed.

Yeah, those were supposed to be logged -- don't know what happened. Thanks for fixing it.