The mozbase unittests don't use mozunit, so their output is confusing in the log.
This makes mozbase output consistent with the rest of the python unittests.
MozReview-Commit-ID: AIs5mza8Rn6
--HG--
extra : rebase_source : 10f65e612f5b3cebb921c47699f5a8be7cd2ba5a
added testing/mozbase to tools/lint/flake8.lint
fixed a first batch of PEP8 errors/warnings
at first the commad autopep8 -i --max-line-length 99 -r -j 8 .
has been used to fix simpler problems, run from testing/mozbase
some of the issues can not easily fixed :
- undefined 'names' in code for example isLinux - isLinux and isBsd "fixed" with # noqa
- undefined 'message' resolved with return fmt.format(...
- undefined 'structured' resolved replacing those with mozlog
- long comments - some remaining - addressed with # noqa
- package level import everything - addressed with # flake8: noqa
restored testing/mozbase/mozdevice/mozdevice/Zeroconf.py
fixed issues reported on mozreview
fixed ')' in testing/mozbase/mozprocess/mozprocess/qijo.py imports
finally fixed multiline string at testing/mozbase/manifestparser/tests/test_manifestparser.py:114
^^^ and again, but now with ./mach python-test --path-only testing/mozbase/manifestparser/tests/test_manifestparser.py passing
fixed testing/mozbase/manifestparser/tests/test_convert_directory.py assert
fixed this error:
10:15:21 INFO - return lambda line: stack_fixer_module.fixSymbols(line)
10:15:21 INFO - TypeError: fixSymbols() takes exactly 2 arguments (1 given)
fixed two spaces lint error even of # noqa comments
restored assignement to lambda with # noqa to silence the lint error
global noqa for testing/mozbase/manifestparser/tests/test_filters.py
stupid is/is not error...
MozReview-Commit-ID: 1FpJF54GqIi
--HG--
extra : rebase_source : 3cf0277fb36a296e3506aeacc2ff05e1b03f9eac
As part of converting WPT to run from a source checkout in automation,
I ran into problems where mozinfo.json wasn't being loaded, causing
several tests to fail. This is because mozinfo.json is only found
from a source directory or from a parent of the WPT meta directory.
Before, mozinfo.json was provided by the "common" tests zip file
and extracted to the base of the destination directory. WPT files
were extracted to a "web-platform" sub-directory. So mozinfo.json
was in a parent directory of "web-platform/meta" and was loaded
automatically.
Now that we want to run WPT out of the source directory, there is
no mozinfo.json and the source directory and no mozinfo.json can be
loaded.
This commit teaches mozinfo.json to look in a MOZINFO_PATH environment
variable for the path to mozinfo.json. This allows mozinfo.json
to exist anywhere on the filesystem. This provides a lot more
flexibility for loading the file.
MozReview-Commit-ID: 1I1cxS1IeyY
--HG--
extra : rebase_source : b06de2b53d3fb26df2c7b1c6d034644c20e47577
As part of converting WPT to run from a source checkout in automation,
I ran into problems where mozinfo.json wasn't being loaded, causing
several tests to fail. This is because mozinfo.json is only found
from a source directory or from a parent of the WPT meta directory.
Before, mozinfo.json was provided by the "common" tests zip file
and extracted to the base of the destination directory. WPT files
were extracted to a "web-platform" sub-directory. So mozinfo.json
was in a parent directory of "web-platform/meta" and was loaded
automatically.
Now that we want to run WPT out of the source directory, there is
no mozinfo.json and the source directory and no mozinfo.json can be
loaded.
This commit teaches mozinfo.json to look in a MOZINFO_PATH environment
variable for the path to mozinfo.json. This allows mozinfo.json
to exist anywhere on the filesystem. This provides a lot more
flexibility for loading the file.
MozReview-Commit-ID: 1I1cxS1IeyY
--HG--
extra : rebase_source : 6fb60257b6a20f6bd79461f1bf1f4f5be1f28072
For contemporary versions of Windows the sys.getwindowsversion call is unreliable
because it depends on a API which had its return value frozen. If we detect this
case use an alternate API instead
For contemporary versions of Windows the sys.getwindowsversion call is unreliable
because it depends on a API which had its return value frozen. If we detect this
case use an alternate API instead
absolute_import was introduced in Python 2.6. There should be no
backwards compatibility concern here.
--HG--
extra : commitid : AhreLXsUlhA
extra : rebase_source : adca67eb99930afbe2d41a55261ce0d3600f315b
Andrew Halberstadt
Gregory Szorc
Ted Mielczarek
Francesco Pischedda
Wes Kocher
Phil Ringnalda
Nicolas B. Pierron
Julien Pagès
Jose Diez
Hiroyuki Ikezoe
James Graham
Ryan VanderMeulen
Henrik Skupin
Edwin Flores
Mike Hommey
Marco Castelluccio
Jonathan Griffin
Jeff Hammel
Siddharth Agarwal
Gervase Markham