Unable to detect module version information

Make sure you have the module enabled. If not, this is the result you will obtain.

Committing attached patch to detect if given project is installed and enabled.

@idlewilder test with drush HEAD and reopen if neccesary.

whoops I missed to remove a print_r() in te previous commit. Now removed. If you see the debug information in your post, [version] is empty. I think it is indicative of 'datestamp' missing in the module's .info.

I didn't ask but do you a cvs checkout of the module? That explains it. In that case you need cvs_deploy, as the status column shows.

I've tested with wysiwyg and no problem so far.

it's not a new dependency. It's neither a dependency strictly speaking. AFAIK it is needed for cvs checkouts as they don't provide a datestamp in the .info file -- that's added by d.o packaging system.

The patch in #2 breaks drush pm-update drupal.

   if (!empty($requests)) {
-    // Force update projects where a specific version is reqested
+    $project_info = drush_get_projects();
+    // Check requests are installed and enabled projects and force
+    // update projects where a specific version is requested.
     foreach ($requests as $name => $request) {
+      print_r($project_info[$name]);
+      if (!isset($project_info[$name])) {
+        drush_set_error('DRUSH_PM_UNKNOWN_PROJECT', dt('!project was not found and will not be updated.', array('!project' => $name)));
+      }
+      elseif (!$project_info[$name]->status) {
+        drush_set_error('DRUSH_PM_DISABLED_PROJECT', dt('!project is not enabled and will not be updated.', array('!project' => $name)));
+      }

The problem we have is that $project_info contains info for all installed modules, but it does not include an entry for 'drupal', so DRUSH_PM_UNKNOWN_PROJECT is set. Unfortunately, the error message is never printed, because updatecode returns TRUE (no error). The calls to drush_set_error above should be return drush_set_error(..., as shown in the enclosed patch. You might prefer to let the loop run and check drush_get_error at the end of the function, but it is important to return FALSE when an error condition occurs, as the drush command dispatcher currently requires this.

Thanks Greg. Commited as is. Perhaps I come back to make it more user friendly in a future.

#2's patch is a bug, but #9's patch does not seem the appropriate solution. Also it seems good to clarify that relates not only to drupal, but with any "package" (i.e. cck etc.).

Update: better expressed.

@luchochs: I don't understand.

@jonhattan: I think that drush_log(..., 'error') might also be a better option here...?

drush_get_projects() returns a unreliable result.
So if I today want to upgrade cck (or any other "package"), I can't.

$ dr up cck
cck was not found and will not be updated.                           [error]
An error occurred at function : drush_pm_updatecode                  [error]
WD php: array_merge(): Argument #2 is not an array in                [error]
/home/lucho/.drush/drushes/drush-TESTS/commands/pm/updatecode.pm.inc
on line 268.
An error occurred at function : drush_pm_update                      [error]

Ah, I see. Today, drush's naming conventions are very confusing in the code. Usually, a project means the name of a collection of modules and/or themes (a "project" on drupal.org). Unfortunately, there are places where drush also uses the word "project" to mean "either a module or a theme". In my opinion, these comments and variable and method names should be changed to avoid confusion. Not sure what they should be changed to; maybe "moduleOrTheme" instead of "project"? A bit wordy. (n.b. Drush does not use the word "package" as you do in #13 (Edit: yes it does), and should not. Since d.o calls projects "projects", so should drush.)

Note that drush help --filter=pm is already pretty accurate on whether an argument should be a project or a module/theme. It seems that the problem is that the argument to pm-update is a project, but the function drush_get_projects() returns a list of modules.

If this is the case, then I would not say that drush_get_projects() does not return an unreliable result, but its use is incorrect in pm-updatecode, because updatecode is expecting a list of project names, but it is instead getting a list of module names. This misuse is in part due to the "fuzzy naming" problem I refer to in the first paragraph of this comment.

Is that correct? If so, I think that the correct solution would be to (a) fix the naming conventions of existing functions, so drush_get_projects becomes drush_get_modules_and_themes (perhaps), and (b) make a new function drush_get_projects that works like drush_get_modules_and_themes, but returns the names of the projects containing the modules and themes returned by said routine.

I noticed that the Drupal docs team has standardized on 'extension' as their word for ModuleOrTheme. We should do the same. That way, we reserve project to refer to a package that contains modules/themes and is downloadable from drupal.org.

Copy & paste the current terminology for a good reference and see what needs to be modified (if that were the case).

/**
 * @file
 *  The drush Package Manager
 *
 * Terminology:
 * - Request: a requested package (string or keyed array), with a project name and (optionally) version.
 * - Project: a drupal.org project, such as cck or zen.
 * - Version: a requested version, such as 1.0 or 1.x-dev.
 * - Release: a specific release of a project, with associated metadata (from the drupal.org update service).
 * - Package: the collection of files that make up a release.
 */

Yes, you are completely correct. Contrary to what I said in #14, the drush package manager uses "package" all over the place. This is confusing, though, since the "package" item in Drupal .info files is used to refer to something completely different: a collection of projects.

From Writing .info files:

package (Optional)
If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here. If left blank, the module will be listed as 'Other'.

I think that "pm" should be renamed to "project manager" for consistency with usage in d.o; I also like Moshe's suggestion to use "extension" to refer to "module or theme", as is also done in d.o.

There is at least one --package flag that will have to change, so this should be done prior to 4.0 stable...

It's not the first time we hit the inconsistency/ambiguity in naming. There's some old issue and I also remember this: http://groups.drupal.org/node/91784#comment-292894

So I'll not repeat myself. On occasion I have proposed 'subproject', that's a weird and unexact word, in the lack of a better one. If 'extension' is the new word for a single .info thing let's use it.

The other problem we have here is the reverse mapping of 'extensions' to 'projects'. Given content there's no direct way to know it is part of cck, although some heuristics can be made (using update service, checking the parent directory name). So some commands works for projects, some for extensions: pm-download cck vs pm-info content.

Perhaps drush.ws could provide such a webservice by leveraging #112692: Drupal ports collection - automate package installation and dependency checking or perhaps http://drupal.org/project/project_api

Re #17 - the usage of 'package' in .info files is unfortunate. We typically use that term in the sense of apt-get and yum. The only time we should use 'package' like .info files uses it is in the listing and filter for pm-list when we are trying to match the functionality of the Modules page.

the word 'extension' is is being used and discussed a bit at #607028: Add README.txt to core.

Yes, I like the idea of #112692: Drupal ports collection - automate package installation and dependency checking quite a bit. Drush can already map from extension to project for downloaded projects; pm-enable does that. That should be enough here, since we are dealing with enabled modules, which therefore must have their dependencies met.

I think these changes in terminology would be appropriate:

  * Terminology:
  * - Request: a requested package (string or keyed array), with a project name and (optionally) version.
- * - Project: a drupal.org project, such as cck or zen.
+ * - Project: a drupal.org project (i.e drupal.org/project/*), such as cck or zen.
+ * - Extension: a drupal.org module or theme.
  * - Version: a requested version, such as 1.0 or 1.x-dev.
  * - Release: a specific release of a project, with associated metadata (from the drupal.org update service).
  * - Package: the collection of files that make up a release.

I agree with Moshe in #19; therefore, the last line in #21 should be removed, and the definition of request should be changed to:

- Request: a requested project (string or keyed array), with a name and (optionally) version

The other changes in #21 are good.

OK, we have some agreement. Someone has to go through the pm.drush.inc and actually implement the terminology changes.

Attached a patch that apparently solves the current problem in this issue, and also addresses the @todos in pm-releases and pm-releasenotes.
It is likely that some project's & package's variables (and flags in the latter case) need to be renamed, but to start I think this is fine.

#24 works great.

The attached patch is the same code as #25, but with updated help text and updated comments. Variable names and array keys are not renamed. We may want to adjust the documentation somewhere (README.txt? Elsewhere?) to explain project / extension / module / theme / etc.

That good! I am trying to find a way of which we can support the DRUSH_PM_DISABLED_PROJECT's check. In the current pach I chose to eliminate it due to the inconsistent results for projects' status (not for the extensions).

The problem described in #26 seems to be fixed now.

P.S.: I exclude myself as a candidate to help with the documentation; yes, too engrish-prone :).

After all of my changes in #25, it made #27 kind of hard to review. It tests out, though, and I think we've met our main objectives for this issue. I suggest that moshe &/or jonhattan should review and commit, and remaining documentation / variable munging should happen in a separate issue.

I'm made a commit reverting #2, #9 and terminology changes based on #27, also including changes in variable and function names.

Following a patch with luchochs' code not shipped in http://drupal.org/cvs?commit=457910 up to discussion.

Here is ~diff between #27 and #29 (it includes #2).

Moving back to the original issue. Some facts:

1. cvs_deploy is required for drush up to work if modules are checked out from cvs. It is required for drush as far as it is also required by update.module. See the cvs deploy page: http://drupal.org/project/cvs_deploy
2. when a list of projects is given to drush up, updatecode will consider you want to explicitly update those projects. It doesn't check the projects are already downloaded and any of its extensions enabled. **It doesn't find the project in the update status info and it assumes the project was checkedout from cvs**.
3. As a consequence of 2) trying drush up anything will print the cvs_deploy message.
4. If cvs_deploy is not in the game update.module and drush up are blind to projects checked out from cvs.

So the problem we have with updatecode is the need to check that requested projects do exist in the filesystem and are enabled. Meaning a project is enabled that any of its extensions is enabled.

We have a similar problem for pm-release/notes. If the solution for updatecode is fine for pm-releases we can fix everything in this issue but the focus must be on updatecode. This other issue is in principle the place to fix pm-release/notes: #977584: Improvements to pm-releasenotes and other commands leveraging it..

patch in the oven.

Good idea to separate the code, all more clear now.
Perhaps even more clearly separate this in:
- #977048 (this issue), and the proposed solution (#2).
- #XXXXXX (e.g. drush_pm_get_extensions()'s refactor), and the proposed solution (#30 for now).

0. I've done a rename of a variable in updatecode.pm.inc. Don't get distracted by the noise.
1. I've moved some functions from includes/environment.inc to pm.drush.inc. Also other functions moved around within pm.drush.inc to be grouped. This is even more noise in the patch,... just put attention on drush_get_projects() and _pm_project_exists_in_drupalorg().
2. new funcion drush_get_projects(): obtain installed project names by interpolation of available extensions. If project was checkd out from cvs and no cvs_deploy it will try to guess the project name based on the parent directory. It doesn't work at all for projects with a directory name badly changed: cck -> mycck; works for a normal case, including cck-DRUPAL-6--2. Reiterate: all of this is only for the case of cvs co and no cvs_deploy. **EDIT** this is a dead end where the ports collection is needed.
3. On topic: updatecode checks for a)not installed projects b)projects with no enabled extensions c)projects from cvs.

Unexistant projects:

$ drush up wysiwygasd
Project wysiwygasd is not installed so it can't be updated.                                                        [error]
An error occurred at function : drush_pm_updatecode                                                                [error]
An error occurred at function : drush_pm_update                                                                    [error]

Projects with all extensions disabled (ignored by update.module):

$ drush up wysiwyg
wysiwyg has no enabled extensions so it can't be updated.                                                          [error]
An error occurred at function : drush_pm_updatecode                                                                [error]
An error occurred at function : drush_pm_update                                                                    [error]

all of this needs a second look from my part. Just wanted to dump it here and continue tomorrow.

I will review tonight after dinner. I'm not a CVS/cvs_deploy-guy, therefore on this subject I may not say much.
For now +1 for the new Doxygen group.

#34's complement:
My opinion based on a couple of tests:
pm-update continues working OK (I can't test #33-3-c).

My opinion based on the code:
We also need drush_get_projects() for pm-releases & pm-releasenotes commands, i.e. we also need drush_get_projects() in _drush_pm_get_releases(). So we need the list of releases for each project.
Basically, I think that drush_get_projects() should be even more drush_pm_get_extensions()-like (when @param $like_projects is TRUE, in #30).

The idea of the new Doxygen group seems to me a good improvement as the new check, i.e. #33-3-c (I repeat: not tested).

Hmm, thinking this a bit more, I'm not sure if it's necessary the new code related to CVS users and no cvs_deploy module.
If the proposed code meets or improves the service provided by cvs_deploy.module, great. Otherwise a warning message like the current I think that would be enough.

Anyway, this issue is too confusing, I think it would be better if we create a issue to define drush_get_projects()'s code (which is the main necessity), then continue with the improvements in some other issue. If it seems appropriate, I have no problems doing so.

Setting status pending arrival of new patch...

More opinions and less ellipsis please.
My opinion.

I've commited the reorganization of some pm- helper functions, the rename of $projects to $update_info in updatecode.pm.inc and two minor fixes. All this was part of my patch in #33. http://drupal.org/cvs?commit=458896

New patch is much more clear.

Sumarizing:
1. introduce new function drush_get_projects(): obtain installed project names off available extensions. It is simplified in regards to my previous patch: it doesn't try to do the magic if cvs_deploy is not present.
2. the function is primarily used by updatecode to check for a)not installed projects b)projects with no enabled extensions c)projects from cvs.
3. change in pm-releases/notes to use the new function.

My opinion on the patch in #39:

+++ commands/pm/pm.drush.inc	3 Dec 2010 17:10:07 -0000
@@ -313,6 +313,66 @@
+function drush_get_projects($extensions = NULL) {
+  if (is_null($extensions)) {
+   $extensions = drush_get_extensions();
+  }

The @param $extensions is not necessary, may be added in the future by not involve changing the function itself.

+++ commands/pm/pm.drush.inc	3 Dec 2010 17:10:07 -0000
@@ -313,6 +313,66 @@
+    if (!isset($extension->info['project'])) {
+      // Checked out from CVS and cvs_deploy is not enabled ?
+      if (!module_exists('cvs_deploy')) {
+        if (is_dir(dirname($extension->filename) . '/CVS')) {
+          drush_log(dt('It seems you are using CVS version of some projects and you don\'t have cvs_deploy module enabled. It is a must to enable cvs_deploy in order to manage those projects succesfully.'), 'warning');
+          continue;
+        }
+      }
+      else {
+        // Custom project.
+        continue;
+      }
+    }

The current check (DRUSH_PM_NO_VERSION) does a good job on this.

+++ commands/pm/pm.drush.inc	3 Dec 2010 17:10:07 -0000
@@ -313,6 +313,66 @@
+    // Bypass extensions in drupal core.
+    if ($extension->info['version'] == VERSION) {
+      continue;
+    }

+++ commands/pm/pm.drush.inc	3 Dec 2010 17:10:07 -0000
@@ -313,6 +313,66 @@
+    // Create/update the project in $projects with the project data.
+    if (!isset($projects[$project])) {
+      $projects[$project] = array(
+        'status' => $extension->status,
+        'extensions' => array(),
+      );
+    }
+    elseif ($extension->status != 0) {
+      $projects[$project]['status'] = $extension->status;
+    }
+    $projects[$project]['extensions'][] = $extension->name;

We need the list of releases for each project (each extension has an array 'releases').

In short: I think we need re-roll #30.

New patch. Changes:

Removed $extensions argument.

function drush_get_projects() {

---

Degraded this log to a debug message.

        if (is_dir(dirname($extension->filename) . '/CVS')) {
          drush_log(dt('Extension !extension is a CVS checkout. Ignoring.', array('!extension' => $extension->name)), 'debug');
          continue;
        }

---

Added project version. Now the check in pm-releases just works.

      $projects[$project] = array(
        'version' => $extension->info['version'],
        'status' => $extension->status,
        'extensions' => array(),
      );

@luchochs the list of releases is not available in $extensions and is not needed in $projects.

We are near the goal. Now suppose I have an installed version of drupal = 6.17.

$ dr upc drupal
Project drupal is not installed so it can't be updated.              [error]
An error occurred at function : drush_pm_updatecode                  [error]

Hm.

$ dr pm-releases drupal
------- RELEASES FOR 'DRUPAL' PROJECT -------
 Release         Date         Status                 
 6.19            2010-Aug-11  Supported, Recommended 
 6.18            2010-Aug-11  Security               
 6.17            2010-Jun-02                         
 6.16            2010-Mar-03  Security               
 6.15            2009-Dec-16  Security               

Hmm.

$ dr rln drupal
------------------------------------------------------------------------------
 > RELEASE NOTES FOR 'DRUPAL' PROJECT, VERSION 6.19:
 > Last updated: August 11, 2010 - 20:41.
 > Note: recommended non-installed version.
------------------------------------------------------------------------------

Hmmm.

And this check is redundant (at least I find no use to it):

+++ commands/pm/pm.drush.inc	4 Dec 2010 18:56:47 -0000
@@ -313,6 +313,59 @@
+    // Projects not packaged by drupal.org.
+    if (!isset($extension->info['project'])) {
+      // Checked out from CVS and cvs_deploy is not enabled ?
+      if (!module_exists('cvs_deploy')) {
+        if (is_dir(dirname($extension->filename) . '/CVS')) {
+          drush_log(dt('Extension !extension is a CVS checkout. Ignoring.', array('!extension' => $extension->name)), 'debug');
+          continue;
+        }
+      }
+      else {
+        // Custom project.
+        continue;
+      }

In short: simpler is better.

With attached patch upc, releases and rln commands work with drupal.

The check for cvs_deploy is not redundant. In fact we need to be more aggresive if the user is using cvs checkouts and cvs_deploy is not enabled: the initial case of this issue --wysiwyg module-- was fixed by checking the extension exists and is enabled. It was wrong because extensions != projects and that solution doesn't work for projects like cck. OTOH, with drush_get_projects() we are unable to obtain the project name from its extensions.

So we need to pay explicit atention to sites using cvs checkouts without cvs_deploy enabled. Options are:

1. the implementation of drush_get_projects() in #33. Discarded. It is better to just copy cvs_deploy to drush.
2. print a warning message in a couple of places: drush_get_projects() and somewhere after bootstrap if --package-handler=cvs was given.

still needs work. I'll give a chance to option 2.

FYI, cvs_deploy will be basically deprecate in mid Feb when drupal moves to git.drupal.org. Then we depend on git_deploy which is at http://drupal.org/project/git_deploy

Changes:

* new _validate() function for package-handler engine backends. It is called in the _validate() of pm-downoad and pm-update.
* extend to git_deploy.
* removed updatecode specific cvs_deploy message. It is never reached because the project can't be detected.

Updated patch after #983222: Suggest releases to download when there is no recommended release; use pm-releases without bootstrapping Drupal

Now we have:

$ drush @wkdev pm-releases devel
Extension eightball is fetched from cvs. Ignoring.                   [warning]
------- RELEASES FOR 'DEVEL' PROJECT -------
 Release         Date         Status                 
 6.x-1.23        2010-Dec-06  Supported, Recommended 

I think that the logic and placement of DRUSH_PM_NO_VERSION was better, wasn't it? If we print the warning in drush_get_projects(), then we see it in instances such as the above, where the warning is accurate, but irrelevant to the operation. Also, the handling of DRUSH_PM_NO_VERSION allowed the warning to appear in the pm-updatecode table, which I think is better than removing the extension from the table.

The other code changes in this patch look and work well.

The underlying logic has changed.

now updatecode checks for existent projects. For drupal (and drush) cck from cvs (and no cvs_deploy enabled) is the same as a not installed or a non-existent project. This is why drush_get_projects() raises a warning. The warning is on the extension, not the project --that is unknown,.. although some extension names match its project name.

At this point, if a project is not found, updatecode can't check for $update_info[$project]. The project is not found and is neither present in $update_info. DRUSH_PM_NO_VERSION is just a non reliable message. It doesn't mind if you did drush up cck or drush up anything. See comments #31 and #45.

The warning make sense for updatecode but I decided to not add a $quiet argument to not disturb other commands because it is hardly needed to enable cvs/git deploy if you're working with checkouts. (I have no problem if you prefer $quite).

In this line, I did introduce the package-handler validator. But it doesn't substitutes the d_g_projects() warning because you can inherit a site that uses cvs checkouts with no cvs deploy, so drush_get_projects()'s warning come to your aid.

I think that the warning should be changed to 'debug' level so that it does not show up in pm-releases, etc., for unrelated projects. The user message should move back to pm-updatecode, but now the thing that upc will be noticing is that it has an extension with an unknown project. "Project not found. Perhaps it was checked out from CVS? Use cvsdeploy."

It would be slick if upc did check for a project name that matched the extension name, as this is common. If found and there is a CVS etc. directory there, then the warning could be more definitive.

I prefer function drush_get_projects($verbose=FALSE) and flag drush_log with a warning or debug, depending.

I also think we shouldn't add to updatecode's table a row for a hipothetical project name that in some probability can match but we can't update anyway (because of the missing cvs_deploy).

Implementation of drush_get_projects() in #33 was an attempt to get the project name for non-drupalorg-packaged projects from the available extensions. I decided to drop that because it was simply easier to ship cvs_deploy (and git_deploy) with drush.

Anyway I don't know if I'm being stubborn here. I'm really blind on what to write in updatecode to improve the scenario when extension name match the requested project. Feel free to provide some code. Consider this options :)

(*) examples and others have all extensions in differente subdirectories. No one in the project root. You need at least two extensions enabled to make _pm_get_project_path() reliable in that case. **EDIT** it is just a extreme case I found with the approach in #33. It is not based on cvs/git deploy approach.

and let's remember.,.. we're discussing on the edge case where someone wants to explicitly update a project that was checked out from cvs/git and cvs_deploy is not ,.....

Yes, I understand the use cases you describe above; thank you for documenting them in the issue.

It comes down to a question of whether it's better to put the wrong information in the table, or to have no information at all, or put the critical information on a line outside the table where it might be missed. I feel that having the info outside the table is only marginally better than not having it, and therefore would prefer to see the information in the table, even though it is potentially wrong. The user is likely to be able to figure out what the project name is, or can follow the instructions to install CVS deploy / GIT deploy to make it right again.

In summary, I prefer current behavior to #48, even though there are some improvements in that patch. If moshe feels otherwise, then I will go along with #48, but I think it should at a minimum be enhanced so that the message includes a note about cvs deploy / git deploy.

Jonhattan, I sent an email in Spanish to better communication. If I made any mistake I apologize, really.

I've commited some parts of the previous patch in #992282: drush_get_projects() to obtain installed projects and fix pm-releases/notes and #992264: Validate package handlers.

Here's a new patch, that fits current implementation (every request in the table). I still want to implement two things but it is reviewable in current status.

What does DRUSH_PM_REQUESTED_PROJECT_NOT_PACKAGED mean? The project exists but there are no releases? I'm unclear about the 'packaged' part.

This is looking way better vis-a-vis approach. I will review more completely later.

Well heck, now I think I'm crazy.

I downloaded a module with --package-handler=cvs (and also used --select --all so that I could start with an old version). I got a warning message that I should use cvs deploy. Awesome.

I enabled the module and tried drush pm-updatecode modulename. I got an error right in the update status table. Even more awesome.

Next I tried drush pm-updatecode. Hm, my new module has disappeared from the table. Not so awesome. I tried again with drush-3.3. Same behavior -- unknown projects do not show up in the table unless they appear on the commandline. Hm.

I thought I had tested that in #49 and #51, but I guess I didn't. I still wish that the unknown module would show up (for every enabled module with unknown project information, put an entry in the table), but since this can be fixed with cvs_deploy and since it has never worked like this before (despite what my deluded memory seems to think it used to do), then I'd say that's a separate issue, and a minor one at that.

As far as I am concerned this is RTBC, clarify the comments per moshe's question in #56. I think I understand the code, though; DRUSH_PM_REQUESTED_PROJECT_NOT_PACKAGED means checked out with cvs rather than downloaded with drush dl --package-handler=cvs, yes? If that explanation is not right, I still think it is okay to clarify with a comment and commit.

I've think of a new approach. It has the same features as before and also add some extras to the table. Perhaps a bit verbose but some messages are ideally to be shown only once (then you go and install cvs_deploy).

Explained with an example:

no cvs_deploy enabled as usual; ask pm-updatecode to update:
* cck (it is a cvs checkout)
* wysiwyg (project not installed)
* googleanalytics (note the project name is google_analytics)
* relativity (extension is disabled)
* views_ui (extension is enabled but the package is views!) **CORRECTION** extension is disabled.
* devel_generate

$ drush up cck wysiwyg googleanalytics relativity views_ui
Update information last refreshed: Thu, 12/09/2010 - 19:01

Update status information on all installed and enabled Drupal projects:
 Name                 Installed version  Proposed version  Status                                   
 Drupal core          6.18               6.19              Update available                         
 Tao                  6.x-3.2            6.x-3.2           Up to date                               
 Zen                  6.x-2.x-dev        6.x-2.x-dev       Update available                         
 Content              Unknown            Unknown           Project was not packaged by drupal.org   
                                                           but obtained from cvs. You need to       
                                                           install cvs_deploy module                
 Number               Unknown            Unknown           Project was not packaged by drupal.org   
                                                           but obtained from cvs. You need to       
                                                           install cvs_deploy module                
 Text                 Unknown            Unknown           Project was not packaged by drupal.org   
                                                           but obtained from cvs. You need to       
                                                           install cvs_deploy module                
 cck                  Unknown            Unknown           Specified project not found              
 wysiwyg              Unknown            Unknown           Specified project not found              
 relativity           6.x-1.4            6.x-1.4           Project has no enabled extensions and    
                                                           can't be updated                         
 google_analytics     6.x-3.0            6.x-3.0           Project has no enabled extensions and    
                                                           can't be updated                         
 views                6.x-2.11           6.x-2.11          Project has no enabled extensions and    
                                                           can't be updated                         

What was done is:
1. all enabled extensions obtained from cvs/git are in the table (content, text, number).
2. cck and wysiwyg are listed as unknown projects.
3. relativity is shown as not updateable because is disabled.
4. views project is selected given its extension views_ui. Similar case for google analytics.

The situation could still be improved for cck,content,text,number by checking extensions path.

This is super-awesome! I'm getting everything I want for Christmas this year.

finally committed!

for the record: DRUSH_PM_REQUESTED_PROJECT_NOT_PACKAGED means the project is from cvs/git and not a drupal.org package (already documented).