Closed (fixed)
Project:
Drush
Component:
Base system (internal API)
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
24 Mar 2011 at 02:17 UTC
Updated:
16 Apr 2011 at 23:21 UTC
An example of the problem is that when I happen to have $options['package-handler'] = 'git_drupalorg'; in my ~/.drush/drushrc.php, the unit tests are slow and they fail. That's because pm-download actually starts using git instead of tarballs. My personal drushrc has polluted the unit test environment. There are more examples of this pollution. If you look at the contextTest, it struggles mightily to not touch files that the current user is managing like the aforementioned drushrc.
Not too fond of my ideas :(. Hoping someone out there has a better one.
Comments
Comment #1
msonnabaum commentedI ran into this as well.
I think our only choice is ignoring any conf that we didn't write ourselves during the test run. We can still have tests that test the loading of the user's conf files, but for the rest of the command tests we should only load temporary confs that we created during setup.
Comment #2
greg.1.anderson commentedTake another look-see at my old bash scripts for producing diagrams for dgd7:
https://github.com/greg-1-anderson/drush-dgd7-scripts
In particular:
https://github.com/greg-1-anderson/drush-dgd7-scripts/blob/master/00-00-...
I just set the HOME environment variable somewhere else; no more pollution from $HOME/.drush/drushrc.php. It might also be a good idea to add a way to call
drush_set_context('ETC_PREFIX', $somewhere_else);to take care of the stuff in /etc/drush.Comment #3
moshe weitzman commentedEnvironment variables saved the day. Committed a fix for this as described by Greg in #2. Most of the changes were to the unit test suite. Drush changes were minor. See http://drupalcode.org/project/drush.git/commitdiff/0f61e3b
Safe to backport, IMO.
Comment #4
msonnabaum commentedBackported along with the tests to 4.