I got tired of typing 'list-projects' all the time.
'list' might be a bit less obviously related to projects, but I don't
think it would be that bad.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
This doesn't affect the default functionality of the runner, but it's
nicer to flash hex files if possible. For example, some tools find it
easier to post-process hex files than binary files for flashing on the
board.
Keep test cases up to date.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Signed-off-by: Michael Scott <michael@foundries.io>
While implementing a manifest-based scan for the zephyr project, I
noticed that we aren't ensuring that projects always have distinct
paths (it's generally OK for them to have non-overlapping names; they
just can't be cloned to the same directories on the file system).
Add a check for that in west.manifest, along with a regression test.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Currently, west.manifest mostly can just return a list of Project
types, each of which is a namedtuple for the project contents we care
about.
It would be better and more flexible to have a "real" data type for
the manifest, along with concrete representations for its contents
such as default values and remotes.
Reimplement the module to add just these things, adding Manifest,
Defaults, and Remote types, and re-working the Project namedtuple into
a class type. All of these (except Manifest) use __slots__ to restrict
their attributes.
Keep the current users and test cases up to date, extending the tests
a bit more as well. This moves a bit more code out of project.py into
west.manifest.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Exercise both invalid manifest detection and correct parsing of valid
manifests. To make it easier to write tests for invalid manifests,
just glob for any invalid_*.yml files in the same directory as the
test file.
Signed-off-by: Marti Bolivar <marti@foundries.io>
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 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>
This doesn't affect the behavior of the current west, but will be
needed to test an upcoming patch which creates and uses that file.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Change the way the project test case fixtures are set up to create
local git repositories in the temporary directory, and a manifest that
refers to them.
This lets the test cases run without a network connection, which is
faster, and avoids false negatives that occur when the test
environment has a bad network connection.
Signed-off-by: Marti Bolivar <marti@foundries.io>
I was confused by the other design, because I intuitively expected West
metadata to go in .west/. To me the other design feels a little bit like
having an empty /home/foo/user/ directory that marks the /home/foo/
directory as containing the user's files.
Use west/ instead of .west/ to avoid "hiding" the implementation of the
building/flashing commands. I would've preferred to split them from the
repo-like functionality instead, but if they're going to be in the same
repository, then it's a decent comprise.
Remove the code that hides the west directory on Windows (via 'attrib')
as well, since it doesn't make much sense anymore.
This commit also fixes a small bug in west_topdir(): A west/ in the root
directory wasn't found.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Analogous to running 'git branch', except for all projects. Also lists
the project(s) each branch appears in.
Example output:
$ python3 -m west branch
FIX-FOO zephyr, Kconfiglib
manifest-rev zephyr, net-tools, Kconfiglib
master zephyr, net-tools
zephyr Kconfiglib
I'm planning to change 'git clone' into 'git init' + 'git remote add' +
'git fetch' later, which avoids creating the last two local branches.
Maybe manifest-rev should be hidden as well.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Passes its command as-is to the shell, within the repositories of each
of the specified projects (or all cloned projects by default).
I was thinking of making the shell quoting for long commands optional,
by joining all the words with a space or the like, but it might get
tricky with argparse. Could look into it more later.
Piggyback some cleanup: Make the absolute path of a project available in
project.abspath, to avoid having to do a bunch of join()s with
util.west_topdir().
Fix some copy-paste comment mess-ups in the tests too.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add simple Google repo-like functionality, for dealing with multiple Git
repositories.
The command set is mirrored after Git. All commands except
'list-projects' accept an optional list of projects, and default to all
(cloned) projects.
- west list-projects
Lists projects and their repositories
- west fetch
Clone/fetch projects. Supports 'clone-depth', for making shallow
clones.
- west rebase
Rebase local branches to the revision specified in the manifest
- west pull
'west fetch' + 'west rebase' (similar to 'sync' in Google repo)
- west branch
Create a new branch in one or more repositories (for working on some
issue)
- west checkout
Check out a branch in each repository that has it. Supports a -b
flag for creating the branch first.
- west diff
Run 'git diff' in each repository
- west status
Run 'git status' in reach repository
There's no way to submit a multi-repository change for review yet.
Currently, a convenience branch 'manifest-rev' is created in each
project, which points to the revision specified for the project in the
manifest. 'manifest-rev' is updated by 'west fetch' and 'west pull'.
Local branches created with 'west branch' are set to track
'manifest-rev'. This makes e.g. a plain 'git status' or 'git pull' work
sensibly even when the manifest revision is an SHA.
We'll see if 'manifest-rev' is too magic later. It's explained in the
help texts of all the relevant commands at least.
It might be nicer to create 'manifest-rev' in e.g. refs/remotes instead
of refs/heads. Git doesn't seem to like trying to create a branch that
tracks a branch in refs/remotes unless it's a "proper" upstream branch
though.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add an exhaustive test suite.
Check expected results for all combinations of runner constructor
parameters, both when instantiating the runner directly via its
constructor and when using command line arguments via its create()
method. Ensure consistent results.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Add test coverage for flash, debug, and debugserver commands, using
runners created directly with their constructors, as well as via
command line arguments, with methods that would run syscalls mocked
out.
Signed-off-by: Marti Bolivar <marti@foundries.io>
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>