The `*.egg-info` directories are needed for the packages to show up as
"distributions" to `pip` and other environment-checking logic.
We know that `*.egg-info` directories are cross-platform because they
exist in the globally-usable `tar.gz` releases of packages.
Differential Revision: https://phabricator.services.mozilla.com/D125909
The `*.egg-info` directories are needed for the packages to show up as
"distributions" to `pip` and other environment-checking logic.
We know that `*.egg-info` directories are cross-platform because they
exist in the globally-usable `tar.gz` releases of packages.
Differential Revision: https://phabricator.services.mozilla.com/D125909
This commit moves the wasm-generate-testuite [1] tool into the
tree so that we have everything we need to update spectests in
one place. Documentation is updated.
Differential Revision: https://phabricator.services.mozilla.com/D111306
Most of the deletions here come from bug 1481612, the `--with-windows-wheel` option to `mach vendor python`, which according to that commit message "is very single-purpose: it's intended to let us vendor an unpacked
wheel for psutil on Windows". Since vendoring `psutil` is something we're no longer doing, we can safely just delete that added code.
Differential Revision: https://phabricator.services.mozilla.com/D90919
Most of the deletions here come from bug 1481612, the `--with-windows-wheel` option to `mach vendor python`, which according to that commit message "is very single-purpose: it's intended to let us vendor an unpacked
wheel for psutil on Windows". Since vendoring `psutil` is something we're no longer doing, we can safely just delete that added code.
Differential Revision: https://phabricator.services.mozilla.com/D90919
Most of the deletions here come from bug 1481612, the `--with-windows-wheel` option to `mach vendor python`, which according to that commit message "is very single-purpose: it's intended to let us vendor an unpacked
wheel for psutil on Windows". Since vendoring `psutil` is something we're no longer doing, we can safely just delete that added code.
Differential Revision: https://phabricator.services.mozilla.com/D90919
Most of the deletions here come from bug 1481612, the `--with-windows-wheel` option to `mach vendor python`, which according to that commit message "is very single-purpose: it's intended to let us vendor an unpacked
wheel for psutil on Windows". Since vendoring `psutil` is something we're no longer doing, we can safely just delete that added code.
Differential Revision: https://phabricator.services.mozilla.com/D90919
We'll add documentation explicitly recommending people use `pyenv` to install Python versions if they can't use their system package manager. Routine usage of `pyenv` will cause this file to be created at the root of the checkout, so ignore it.
Differential Revision: https://phabricator.services.mozilla.com/D82609
This includes scripts that involve `tup`, jobs that build `tup` in automation, `tup.configure`, and related infrastructure and documentation.
Differential Revision: https://phabricator.services.mozilla.com/D73921
The process of importing spec-tests is confusing and has some tricks that
I should write down. The files are also scattered around, so I've tried to
move them all into one spot.
* Moves wasm/Makefile to jit-test/etc/wasm
* Moves jit-test/etc/wasm-config[-lock].toml to jit-test/etc/wasm
* Adds jit-test/etc/wasm/README.md
Differential Revision: https://phabricator.services.mozilla.com/D69902
--HG--
rename : js/src/wasm/Makefile => js/src/jit-test/etc/wasm/Makefile
rename : js/src/jit-test/etc/wasm-config-lock.toml => js/src/jit-test/etc/wasm/config-lock.toml
rename : js/src/jit-test/etc/wasm-config.toml => js/src/jit-test/etc/wasm/config.toml
extra : moz-landing-system : lando
This switches our test import Makefile to use the wasm-generate-testsuite tool
for importing spec-tests. A new config file declaring the proposals to import,
along with tests to skip, is added to jit-test/etc.
There was an ability to apply a .patch file to paper over a back-compat issue
is types.wast.js. It appears that newer spec/tests don't include a types.wast,
so I don't think this patch is necessary anymore. We can add this ability back
later if needed.
Differential Revision: https://phabricator.services.mozilla.com/D65195
--HG--
extra : moz-landing-system : lando
This adds a tp5n-multiproc output directory which contains postprocessed
versions of the tp5n set. They are processed to take iframes with relative
URLs and output absolute URLs with domains similar to their original
domains. This will help us better simulate a real-world case for Fission,
which will split processes based on the ETLD+1 of the domain.
Differential Revision: https://phabricator.services.mozilla.com/D53065
--HG--
extra : moz-landing-system : lando
We vendor the Puppeteer library, but not its dependencies.
When "npm install" is called in remote/test/puppeteer/, it puts
its dependencies under remote/test/puppeteer/node_modules/ and
generates a remote/test/puppeteer/package-lock.json file. We do
not want these to be checked in.
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D37010
--HG--
extra : moz-landing-system : lando
We vendor the Puppeteer library, but not its dependencies.
When "npm install" is called in remote/test/puppeteer/, it puts
its dependencies under remote/test/puppeteer/node_modules/ and
generates a remote/test/puppeteer/package-lock.json file. We do
not want these to be checked in.
DONTBUILD
Differential Revision: https://phabricator.services.mozilla.com/D37010
--HG--
extra : moz-landing-system : lando
browsertime-results is the default output directory for mach browsertime. It should be part of hgignore to not clutter the workspace.
Differential Revision: https://phabricator.services.mozilla.com/D34389
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
This also removes the lalrpop files from the .git/hgignore as that
breaks the build since lalrpop now includes lrgrammar in the published
crate and that file needs to be vendored
--HG--
extra : histedit_source : e31c07645a87a11b19a0b7e44f2a48d791b5f396
Scott
Ting-Yu Lin
Julian Descottes
Greg Tatum
Mathew Hodson
Mitchell Hentges
criss
Andi-Bogdan Postelnicu
Andrei Oprea
Ryan Hunt
Ricky Stewart
Noemi Erli
Mihai Alexandru Michis
smolnar
Dan Mosedale
Tom Prince
Maja Frydrychowicz
Nick Alexander
Doug Thayer
Dzmitry Malyshau
Henrik Skupin
Mike Conley
Andreas Tolfsen
Ciure Andrei
Ed Lee
Carolina
Florin Strugariu
Denis Palmeiro
k88hudson
Razvan Maries
Bastien Orivel
Dave Townsend
Jason Orendorff
Nicolas Silva
Tooru Fujisawa