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>
In order to support encoding the required west URL and revision when
tagging a manifest for a release, move the metadata regarding west
itself (url and revision) from the command-line to the manifest.
This involves:
- Adding a new "west" section to the manifest that includes the metadata
- Removing the "-w" and "--wr" command-line options
- Parsing the "west" section of the manifest directly in the
bootstrapper
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Using `-u` as the manifest URL is confusing because:
* We use `-w` for the west url
* We use `--wr` for the west revision
* We use `--mr` for the manifest revision
Instead, use `-m` which is consistent with the rest of the options.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
We are getting user feedback about missing dependencies (like
"commands" and "log") that are actually imports of internal west
modules by those names.
We've been playing games with the python path to omit typing "west",
but this always caused inconsistency (as the bootstrapper version is
imported as west._bootstrap.version) and now it's causing outright
user confusion.
Let's just be consistent and import everything as west.xxx.
Fixes#57.
Signed-off-by: Marti Bolivar <marti@foundries.io>
The instructions for using an arbitrary west installation are OK, but
the docs on how to create and install a custom bootstrapper could use
some fixes. Change them to build and install the bootstrapper from a
wheel instead, and provide instructions for how to back that change
out.
(Prefer wheel here to follow the general trend treating them as the
favored package format, and also because the wheel format is
cross-platform.)
While we're here, remove the instructions on executing directly out of
the repository. You can run a custom "main" west via instructions that
are added in this patch, and it doesn't make much sense to run the
bootstrapper unless you've installed it as an entry point script
somewhere.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Remove support for python setup.py test in favor of an
environment-variable based approach. Add Windows instructions as well.
With this patch, west can now be installed from a setuptools source
distribution (sdist), e.g. with "pip3 install west-0.1.99.tar.gz".
Signed-off-by: Marti Bolivar <marti@foundries.io>
The self-update mechanism checks the West and manifest repositories in
west/ for upstream changes and rebases them to the latest version if any
are found.
'west fetch' and 'west pull' run a self-update before fetching any
project data. It probably makes sense to always work with the latest
version of West and the manifest there. The self-update can be
suppressed with --no-update.
There's also a 'west update' command for manually updating West and/or
the manifest.
West automatically restarts itself after a self-update, before running
any commands or parsing the manifest. This makes it safe to add a new
feature to West and immediately start using it in the manifest.
The restarting is done with a plain exec(3). Getting this to work
required a few changes:
- West now uses absolute instead of relative imports, to make it
possible to execute src/west/main.py directly. This also makes it a
bit simpler to work on West. Relative imports seem to be discouraged
when googling around a bit.
__init__.py was removed from src/west. West is more of an application
than a package now (though it uses some packages internally).
- The internal 'cmd' package was renamed to 'commands', to avoid
clashing with a module in the Python standard library.
'runner' was renamed to 'runners' as well, for consistency.
The tests now have to be run from the West repository root with
'PYTHONPATH=src/west pytest'. The previous testing setup "just working"
relied on having run 'pip3 install -e .' first, which happened to add
src/west to the path due to the bootstrap script being there.
__init__.py was removed from the test directories as well. Packages
mostly make sense for tests if there are naming collisions, and naming
collisions will be obvious if packages aren't used.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Follow along with what the cool kids are doing and add py.test
integration.
This patch doesn't add any test cases, but sets up packages to
test the runner classes as additional work.
To run the test suite, use:
$ python3 setup.py test
Since there are no tests, these pass.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Add a separate package for bootstrapping West and a Zephyr manifest
repository, and have the setuptools integration install that instead
of the "real" West.
Signed-off-by: Marti Bolivar <marti.f.bolivar@gmail.com>
Michael Zimmermann