This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
--HG--
extra : commitid : 6tFME1KKfTD
extra : rebase_source : 78728f82f5487281620e00c2a8004cd5e1968087
Neither of these clients are used on Android, and the Bagheera client isn't
used anywhere unless Firefox Health Report is enabled.
This patch conditionalizes their inclusion in services-common, makes the tests
aware, and also tests that they are _not_ present on Android.
Note that some unused test helpers are also omitted.
Neither of these clients are used on Android, and the Bagheera client isn't
used anywhere unless Firefox Health Report is enabled.
This patch conditionalizes their inclusion in services-common, makes the tests
aware, and also tests that they are _not_ present on Android.
Note that some unused test helpers are also omitted.
Back when mozpack.path was added, it was used as:
import mozpack.path
mozpack.path.func()
Nowadays, the common idiom is:
import mozpack.path as mozpath
mozpath.func()
because it's shorter.
$ git grep mozpath\\. | wc -l
423
$ git grep mozpack.path\\. | wc -l
123
This change was done with:
$ git grep -l mozpack.path\\. | xargs sed -i 's/mozpack\.path\./mozpath./g'
$ git grep -l 'import mozpack.path$' | xargs sed -i 's/import mozpack.path$/\0 as mozpath/'
$ (pat='import mozpack.path as mozpath'; git grep -l "$pat" | xargs sed -i "1,/$pat/b;/$pat/d")
It was observed that FHR was sending invalid JSON payloads to the
server. Specifically, JSON payloads contained invalid Unicode strings.
Investigation revealed that the culprint was CommonUtils.convertString()
silently swallowing high bytes. When the Bagheera client went to gzip
the JSON payload, the input buffer into gzip was missing high bytes.
This patch changes the bagheera client to UTF-8 encode strings before
gzip, thus ensuring all data is preserved. A corresponding change was
also added to the mock bagheera server implementation.
Alternatively, we could have changed CommonUtils.convertString() to
be high byte aware. However, many consumers rely on this function.
This patch is written with the intent of being uplifted and the change
performed is targeted at the specific problem.
Tests for Unicode preserving behavior have been added to both the
generic Bagheera client and to FHR. The latter test is arguably
not necessary, but peace of mind is a good thing, especially with
FHR.
See also bug 915850.
--HG--
extra : rebase_source : 4efddea7767c2e5f8cf19df247c3aba07c40eec6
extra : amend_source : ae3b6d89efa54fc9ed1794404476622946ad4b22