Recent versions of mypy have learned that the yaml module has type
stubs and the tool is now erroring out when it discovers we import
yaml since the stubs are not involved.
This is breaking CI on unrelated patches; fix it following the
instructions here:
https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Based on: 8875340db4
Signed-off-by: Michael Zimmermann <michael.zimmermann@grandcentrix.net>
There's just one test that's being skipped this way, and it's not that
slow compared to the rest.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We no longer need to filter based on the platform like this. Our tests
know what to do at runtime.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Recent versions of tox are complaining with errors that look like
this:
WARNING: test command found but not installed in testenv
cmd: C:\Users\Marti\Envs\west-dev\Scripts\mypy.EXE
env: C:\Users\Marti\src\west\.tox\py3-windows
Maybe you forgot to specify a dependency? See also the allowlist_externals envconfig setting.
DEPRECATION WARNING: this will be an error in tox 4 and above!
Fix that by running all the dependencies through the python binary in
the tox virtualenv. Moving the dependencies out of tox.ini seems to be
necessary too; I couldn't get this to work otherwise. It's more in
keeping with the style in the docs here anyway:
https://tox.readthedocs.io/en/latest/config.html
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These changes introduce initial support for type hints. Support for mypy
static analysis on GitHub workflows has also been enabled.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
I keep running into edge cases trying to get proper import loop
detection going, so just catch the RecursionError it causes and
convert it to ManifestImportFailed.
Testing this takes a while, so we only will do that from CI for now.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The linter finishes in a few seconds and its errors can be addressed
quickly, whereas the test suite takes a bit longer to run. Let's do
the fast thing first.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We used to use two newlines between definitions but then gradually
stopped doing that. Formalize that.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Add a topdir argument to each of these functions:
- read_config()
- update_config()
- delete_config()
If set, then topdir/.west/config will be used as the local
configuration file if necessary. This allows users of this module to
decouple themselves from west.util.west_dir() without having to resort
to temporarily setting environment variables.
Keep the tests up to date, adding a couple of test cases to make sure
the new kwarg works as expected.
While we're here, re-work the fixture setup so we don't ever have to
monkey-patch west.configuration._location() by always pointing the
WEST_CONFIG_xxx environment variables inside the tmpdir we're running
each test case from. This lets us avoid some extra work in tox.ini and
makes the resulting test code easier to read, without sacrificing any
safety in terms of touching the user's actual files.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Don't copy the west tree; tox already installs it for us into the new
virtualenv, and we don't run any code out of a checked out repository
anymore, so doing things related to that is unnecessary.
This also makes the tests run a little bit faster (around a 5% or more
speedup on my system).
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Fixes: #198#213
This commit add the command `west config` for getting and setting of
key - value pairs in:
- Project specific: `<project>/.west/config`
- Global specific: `~/.westconfig`
- System specific, Linux:`/etc/westconfig`
MacOS: `/usr/local/etc/westconfig`
Windows: `%PROGRAMDATA%/west/config`
It also includes corresponding test cases.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Add a flake8 configuration to the tox testing. This enforces a
consistent style. Clean up remaining issues around the codebase.
Disable a handful of flake8's complaints when the style seems popular
enough among the team members to ignore.
Signed-off-by: Marti Bolivar <marti@foundries.io>
To properly test the project commands, it would be best to have a
fresh west bootstrapper package created and installed on PATH, so it
could be used to run commands exactly as they'd happen if we package
and ship the working tree.
To make that easier, add a dependency on tox and use it for testing:
https://tox.readthedocs.io/en/latest/
From now on, we'll test west by running 'tox' from the repository
root. This has several advantages over running pytest directly:
- "Just run tox": there are no longer any differences in test invocation
between POSIX OSes and Windows.
- tox creates an sdist package of the current tree using our setup.py
and installs it into a new virtual environment, then runs tests
there. This removes interference from other packages installed on
the host (like released bootstrappers that are also installed)
- we get to run multiple shell commands in order, should that ever be needed,
in our test procedures in a way that won't affect users
With that done, we can re-work the multirepo command testing to invoke
the bootstrapper in the virtual environment, adding various tests and
filling in longstanding testing gaps by adding increased checking of
the results (currently, much of the testing just checks whether
commands do or do not error out, which isn't enough).
These changes were made with a view towards the upcoming changes which
are planned before releasing west "into the wild": the test case code
should be mostly the same before and after the changes, so this serves
as a good baseline against regressions introduced by those upcoming
changes.
Signed-off-by: Marti Bolivar <marti@foundries.io>
[wip] debugging shippable results
Signed-off-by: Marti Bolivar <marti@foundries.io>
[wip] just test one py3
shutil.which west is picking up a 3.4 version in the 3.6 test, oddly
Signed-off-by: Marti Bolivar <marti@foundries.io>