Merge lp:~gagern/bzr/bash_completion-ExecutableFeature into lp:bzr
| Status: | Merged |
|---|---|
| Approved by: | Robert Collins on 2010-05-25 |
| Approved revision: | 5171 |
| Merged at revision: | 5255 |
| Proposed branch: | lp:~gagern/bzr/bash_completion-ExecutableFeature |
| Merge into: | lp:bzr |
| Prerequisite: | lp:~gagern/bzr/bug560030-include-bash-completion-plugin |
| Diff against target: |
122 lines (+42/-27) 3 files modified
NEWS (+4/-0) bzrlib/plugins/bash_completion/tests/test_bashcomp.py (+5/-27) bzrlib/tests/features.py (+33/-0) |
| To merge this branch: | bzr merge lp:~gagern/bzr/bash_completion-ExecutableFeature |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Robert Collins (community) | Needs Fixing on 2010-05-25 | ||
| John A Meinel | 2010-05-08 | Needs Information on 2010-05-18 | |
|
Review via email:
|
|||
Commit Message
Generalise probing for executables used in selftest.
Description of the Change
If the bash_completion plugin gets merged into the bzr source tree, here is a subsequent testing framework improvement that might benefit tests for other commands and plugins as well. The class ExecutableFeature checks for the availability of a named executable on the PATH.
- 5169. By Martin von Gagern on 2010-05-18
-
Handle empty PATH elements in ExecutableFeature.
| Robert Collins (lifeless) wrote : | # |
This feature seems to be written a little awkwardly to me - just defining _probe and the string should be enough, no ?
| Martin von Gagern (gagern) wrote : | # |
@jameinel: subprocess.
1. additional shell invocation causes overhead for one more process
2. can't easily test for existence of command without actually executing it
3. might under some circumstances interfere with shell builtins
So iterating over PATH seems to me to be both cleaner and more performant
@lifeless: I want the path property available so I can execute the found executable by full path name without repeating the search, the way the bash_completion plugin tests do.
And I don't want to impose any restriction about in which order on feature check and access to the path property. Therefore both the feature check and access to the path both should essentially do the same: try to locate the executable upon first run, use cached result afterwards. Under these circumstances, _probe seems the wrong approach, as it is based on a different assumption, namely a boolean-only feature with no additional properties.
What might feel awkward as well is the fact that self._path is not initialized, but only set lazily at first access. Basically I have three possible states: _path is either unset, set to None, or set to some string. It would be easy to either have self._path initialized to a special value, denoting "no cached value", or to have a separate member track whether or not the result has been cached already. But as the simple try-except does the job well, and easily represents the three states named above, I went for that solution.
| Robert Collins (lifeless) wrote : | # |
>>> @lifeless: I want the path property available so I can execute the found executable by full path name without repeating the search, the way the bash_completion plugin tests do.
But if the feature isn't available, the path is useless. So the
feature *has* to be checked first.
I'm totally fine with the caching - thats standard for features. It
just seems a lot more awkward than simply having probe set the _path.
-Rob
- 5170. By Martin von Gagern on 2010-05-25
-
Have ExecutableFeature implement and use _probe.
Setting _path now is a side-effect of _probe.
This makes Robert Collins happy.
| Robert Collins (lifeless) wrote : | # |
One last thing, rather than SedFeature, sed_feature please, and put them in features? [we've changed coding style in this regard].
Cheers,
Rob
- 5171. By Martin von Gagern on 2010-05-25
-
Move ExecutableFeature instances to tests.features module.
| Robert Collins (lifeless) wrote : | # |
sent to pqm by email

Note that I think you could do this using a 'subprocess. Popen() ' style feature, rather than iterating over environ['PATH'].
Does that seem reasonable to you?