Merge lp:~gz/bzr/path_from_environ_832028 into lp:bzr
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Vincent Ladeuil | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 6369 | ||||
Proposed branch: | lp:~gz/bzr/path_from_environ_832028 | ||||
Merge into: | lp:bzr | ||||
Diff against target: |
372 lines (+87/-99) 4 files modified
bzrlib/osutils.py (+31/-24) bzrlib/tests/test_lockdir.py (+2/-1) bzrlib/tests/test_osutils.py (+0/-6) bzrlib/win32utils.py (+54/-68) |
||||
To merge this branch: | bzr merge lp:~gz/bzr/path_from_environ_832028 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Vincent Ladeuil | Needs Fixing | ||
Review via email: mp+85388@code.launchpad.net |
Commit message
Add path_from_environ and clean ups to osutils and win32utils
Description of the change
The basic idea behind this branch is to add an interface for retrieving a path from the environment, it's just a little bogged down in osutils/win32utils tech debt.
The main drawback apart from that is that paths really are bytestrings on nix, and in a couple of places can get away with that (at least until they wind up in an exception object or similar). Without a bigger fix for lots of apis, this is pretty intractable unfortunately.
Because a few things need working out still, I've not pushed the bzrlib.config changes, this probably wants coordinating with Jelmer's changes:
<https:/
The background is this merge proposal:
<https:/
Also want to unblock this one by fixing the various underlying api issues:
<https:/
Proposing despite my confusion for some feedback.
20 + # GZ 2011-12-12:Ideally want to include `key` in the exception message BadFilenameEnco ding(val, _fs_enc)
21 + raise errors.
Any reason for not defining an exception derived from BadFilenameEncoding or
just make it a bit more customizable ?
24 +def _posix_ getuser_ unicode( ): user_encoding) BzrError( "Encoding of username %r is unsupported by %s "
25 + """Get username from environment or password database as unicode"""
26 + name = getpass.getuser()
27 + user_encoding = get_user_encoding()
28 + try:
29 + return name.decode(
30 + except UnicodeDecodeError:
31 + raise errors.
32 + "application locale." % (name, user_encoding))
Beware here that we had at least one case (savannah ?) where the /etc/passwd
contained utf-8 names while running under C locale.
The weird thing is that I kind of remember specific code for that... but
can't find it with a quick search. Hints includes: poolie, locks (?) and
pwd...
95 +# GZ 2011-12-12: These tests escape isolation and look at the GlobalConfig get_username_ for_lock_ info o(TestCase) :
96 +# of the user through lockdir.
97 class TestLockHeldInf
Right, use TestCaseInTempDir then ;)
On the other hand, if you have a trick to better detect this kind of issue
(how did you find it in this case ?), let's generalize the check (if
possible, I know I encountered cases in the past where this wasn't
possible).
108 - def test_no_ username_ bug_660174( self):
Can you just briefly explain why the bug (hence this test) is not relevant
anymore ?
223 - windir = os.environ. get('windir' ) unicode( 'WINDIR' )
224 + windir = get_environ_
Env vars are not case sensitive on windows ? Worth a reminding comment ;)
Say, in the docstring of the win32utils module ?
Your proposal deletes a lot of 'Returned value can be unicode or plain
string.' which is a huge win ! Thanks.
What's the status now ? We can safely get unicode strings from the
environment, distinguishing paths (fs_encoding) from the rest
(user_encoding), trapping illegal byte strings (good).
From there we chase all remaining call to os.environ.get ?
About "illegal" byte strings, I see two cases:
- paths inside a bzr controlled tree (I don't know a case where such a path
is used in an env var, so we don't have to care),
- paths containing a bzr controlled tree: sorry guys, we don't support that
and we abort as soon as we encounter an env var with such a path.
Is that correct ?
If yes, then pending the minor tweaks mentioned above, that's a significant improvement that I'd like to see landed ASAP !