Closed (fixed)
Project:
Drush
Component:
Base system (internal API)
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
25 Apr 2012 at 16:55 UTC
Updated:
31 May 2012 at 19:00 UTC
Jump to comment: Most recent file
if we lazy programmers do
drush_invoke_process('@self', 'foobar')
errors should be integrated by default.
in doubt be verbose.
otherwise we might get lots of issues like #1547446: Update error not debuggable: "The external command could not be executed due to an application error"
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 0001-implement-1547432-drush_invoke_process-should-defaul.patch | 1.26 KB | geek-merlin |
Comments
Comment #1
geek-merlinComment #2
greg.1.anderson commentedThis change could not go into Drush-5; it would have to be a Drush-6-only change.
I know Drupal folks are not big on backwards compatibility, but it took a long time to get just the Features module to sync with changes to backend invoke made in Drush 5. I am therefore reluctant to change default behavior unless it is really important to do so.
Comment #3
moshe weitzman commentedSince we haven't branched for Drush6 yet, this needs to wait a bit.
I defer to Greg's decision about backporting to Drush5. Folks should provide input here if they feel strongly.
Comment #4
greg.1.anderson commentedThis issue is driving me crazy. Back in #1313810: #integrate consistency betwen drush-4 and drush-5, we explicitly set the default #integrate to TRUE for Drush-4.5, on the excuse that we wanted to make it consistent with Drush-5. Somehow, I thought that #1 was going back to the pre-#1313810 state of things, and I hate flip-flopping, but now I see, though, that Drush-5 is defaulting to FALSE, and #1 wants to make things the way they were supposed to be when #1313810 was committed to the 4.x branch.
I don't know how we got here, but I committed #1, and we're just going to move forward from here. Code that currently depends on the FALSE default will just get a little noisier, which is not terrible.
Comment #5
moshe weitzman commentedSounds like a good resolution. Thanks Greg.
Comment #6
zbricoleur commentedI'm not seeing any difference when I apply this patch. I still get the error message with no explanation. Am I looking in the wrong place, or...what?
Comment #7
greg.1.anderson commentedThis has been fixed and committed to the master branch; use the latest code from git to test. Based on your question above, though, I'm not sure that you are talking about the same issue that is being discussed here. Please open a new issue, and follow the reporting guidelines if you are still having trouble.
Comment #8.0
(not verified) commentedcrosslinked