[PATCH 3 of 3 v2] run-tests: use strings for env object

timeless timeless at gmail.com
Thu May 5 07:09:11 EDT 2016


I just spent some time investigating this.

The answer is: NO. WE SHOULD NOT USE environb.

That's an awful red herring.

os.environb

Bytes version of environ: a mapping object representing the
environment as byte strings. environ and environb are synchronized
(modify environb updates environ, and vice versa).

environb is only available if supports_bytes_environ is True.

New in version 3.2.

https://docs.python.org/3/library/os.html#os.environb

os.supports_bytes_environ

True if the native OS type of the environment is bytes (eg. False on Windows).

New in version 3.2.

https://docs.python.org/3/library/os.html#os.supports_bytes_environ

Trying to use environb would break python3 on windows because we'd
have an os.environ object instead of an os.environb object, and we'd
be trying to stash bytes into it.

I'm going to reassert that what I'm doing is correct. And I'd like to
get a version of it in so that I can unclutter my repository. I have a
whole slew of things that are blocked by this. Especially test.env
work.

I will send a patch to *REMOVE* all use of environb and an item for
check code to reject it.

On Thu, Mar 31, 2016 at 9:39 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> On Wed, 30 Mar 2016 03:29:53 -0500, timeless wrote:
>> # HG changeset patch
>> # User timeless <timeless at mozdev.org>
>> # Date 1459319268 0
>> #      Wed Mar 30 06:27:48 2016 +0000
>> # Node ID 3ac7919ccd75ec18862379804a4227f652f346c3
>> # Parent  bc149b7f13ad842e7945704a6b27467a1481dab4
>> run-tests: use strings for env object
>>
>> diff --git a/tests/run-tests.py b/tests/run-tests.py
>> --- a/tests/run-tests.py
>> +++ b/tests/run-tests.py
>> @@ -804,14 +804,16 @@
>>              offset = '' if i == 0 else '%s' % i
>>              env["HGPORT%s" % offset] = '%s' % (self._startport + i)
>>          env = os.environ.copy()
>> -        env['TESTTMP'] = self._testtmp
>> -        env['HOME'] = self._testtmp
>> +        testtmp = self._testtmp.decode('utf-8')
>> +        threadtmp = self._threadtmp.decode('utf-8')
>> +        env['TESTTMP'] = testtmp
>> +        env['HOME'] = testtmp
>>          # This number should match portneeded in _getport
>>          for port in xrange(3):
>>              # This list should be parallel to _portmap in _getreplacements
>>              defineport(port)
>> -        env["HGRCPATH"] = os.path.join(self._threadtmp, b'.hgrc')
>> -        env["DAEMON_PIDS"] = os.path.join(self._threadtmp, b'daemon.pids')
>> +        env["HGRCPATH"] = os.path.join(threadtmp, '.hgrc')
>> +        env["DAEMON_PIDS"] = os.path.join(threadtmp, 'daemon.pids')
>
> This seems going to the opposite direction. We generally avoid encoding
> problems by not using unicode objects.
>
> Perhaps it should use os.environb on Python 3.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list