pm-readme command

+1 for pm-readme. Patches welcome; this would be a simple call to wget/curl, and there is a drush_download_file that will do that for you. For example:

http://drupalcode.org/project/drush.git/blob/HEAD:/README.txt

Would it make sense to name it different and let it support an extra type argument? So it could print README.txt, CHANGELOG.txt, INSTALL.txt etc.?

And instead of HEAD should it print the file from the recommended release tag, for example http://drupalcode.org/project/views.git/blob_plain/refs/tags/6.x-2.16:/R....

The majority of projects out there don't even have the .txt extension for their documentation files:
https://github.com/apenwarr/git-subtree

I have also seen README.md.

Fast made a patch to implement a pm-readme command. It has some issues....

• It's hardcoded to README.txt
• The approach about fetching the README file from drupalcode.com using drush_download_file(), is not working that well. drupalcode.com returns an error 500 if the file does not exist in the repository instead of a 404. drush_download_file() does not handle this, and saves the content of the error 500 page.....See for example http://drupalcode.org/project/yahoo_geocoding_api.git/blob_plain/refs/he... and http://drupalcode.org/project/yahoo_geocoding_api.git/blob_plain/refs/he...
• The command also need some log messages and error handling.

Good start. The next step would be to pull down a directory listing (e.g. http://drupalcode.org/project/drush.git/tree) and scan through it, looking for files that match README.*. After grabbing the contents of the above URL, I would do a preg_match for <a href="([^"]*)">raw</a> (n.b. hand-typed, not tested); then you'd have a bunch of matches that contained URLs of stuff to download, and you could just do a case-insensitve compare against the end of each URL, ignoring extensions, to find the file to grab.

If you did that, then handling the awkward internal server error pages in drush_download_file wouldn't be too important.

Thanks, Greg. I will make a new patch implementing your suggestions. It will probably first be tomorrow though.

Attached an updated patch based on the suggestions in #6. It know uses the Git tree listing for finding a README file. It's no longer hardcoded to README.txt, but just takes the first and best README file. Logging is also implemented.

Looks good, and works great. I am seeing a couple of warnings in updatexml, but that's someone else's code.

I think this works well enough to be committed, but I'll wait for other maintainers to review.

This scraping of updatecode might be too hackish for drush core. I'll mull it. Also, this might want integration into pm-download and pm-updatecode like our --notes option

Please don't commit yet.

I don't know if I would call this "scraping" of updatecode; maybe it is inappropriate intimacy. Perhaps a good way to handle this would be to call pm-releases via backend invoke, and parse the $values array returned. We'd first have to make sure that pm-releases returned its releases array as the function result of its command callback, so that this info is available in the values array.

I'm kinda disinterested in this for drush core. Please submit it as a contrib extension. I think it will be popular there. Thanks for the contribution.

I will make a pm-readme patch for drush_extras, and try to get it into that module.

I'll take pm-readme in drush extras.

Moving to Drush extras queue.

Is this implemented now?

I think there's a dup issue somewhere in the Drush queue with most of an implementation sitting around somewhere. If I remember correctly, it was not accepted for Drush, but could be committed here if someone found and finished it.

Thanks Greg, maybe that would be a good project for me to get my feet wet with :D.

Oh, the last patch is above, in #8. :p Didn't scroll up. Just needs a little re-work to call pm-releases with drush_invoke_process, and it's good to go.

K, I will play with it sometime. No promises :D