zephyrproject-rtos / west Goto Github PK

View Code? Open in Web Editor NEW

200.0 24.0 106.0 1.48 MB

West, Zephyr's meta-tool

Home Page: https://docs.zephyrproject.org/latest/guides/west/index.html

License: Apache License 2.0

Python 100.00%

repository-management flashing debugging build-tool zephyr

west's Introduction

This is the Zephyr RTOS meta tool, west.

https://docs.zephyrproject.org/latest/guides/west/index.html

Installation

Using pip:

pip3 install west

(Use pip3 uninstall west to uninstall it.)

Basic Usage

West lets you manage multiple Git repositories under a single directory using a single file, called the west manifest file, or manifest for short. By default the manifest file is named west.yml. You use west init to set up this directory, then west update to fetch and/or update the repositories named in the manifest.

By default, west uses upstream Zephyr's manifest file, but west doesn't care if the manifest repository is zephyr or not. You can and are encouraged to make your own manifest repositories to meet your needs.

For more details, see the West guide in the Zephyr documentation.

Example usage using the upstream manifest file:

mkdir zephyrproject && cd zephyrproject
west init
west update

What just happened:

west init clones the upstream west manifest repository, which in this case is the zephyr repository. The manifest repository contains west.yml, a YAML description of the Zephyr installation, including Git repositories and other metadata.
west update clones the other repositories named in the manifest file, creating working trees in the installation directory zephyrproject.

Use west init -m to specify another manifest repository. Use --mr to use a revision to inialize from; if not given, the remote's default branch is used. Use --mf to use a manifest file other than west.yml.

Additional Commands

West has multiple sub-commands. After running west init, you can run them from anywhere under zephyrproject.

For a list of available commands, run west -h. Get help on a command with west <command> -h.

West is extensible: you can add new commands to west without modifying its source code. See Extensions in the documentation for details.

Running the Tests

First, install tox:

# macOS, Windows
pip3 install tox

# Linux
pip3 install --user tox

Then, run the test suite locally from the top level directory:

tox

You can use -- to tell tox to pass arguments to pytest. This is especially useful to focus on specific tests and save time. Examples:

# Run a subset of tests
tox  --  tests/test_project.py

# Debug the ``test_update_narrow()`` code with ``pdb`` (but _not_ the
# west code which is running in subprocesses)
tox  --  --verbose --exitfirst --trace -k test_update_narrow

# Run all tests with "import" in their name and let them log to the
# current terminal
tox  --  -v -k import --capture=no

The tests cannot be run with pytest directly, they require the tox environment.

See the tox configuration file, tox.ini, for more details.

Hacking on West

This section contains notes for getting started developing west itself.

Editable Install

To run west "live" from the current source code tree, run this command from the top level directory in the west repository:

pip3 install -e .

This is useful if you are actively working on west and don't want to re-package and install a wheel each time you run it.

Installing from Source

You can create and install a wheel package to install west as well. The wheel Python package is required to do this. See "Installing Wheel" below if you need to do this.

To build the west wheel file:

# macOS, Linux
python3 setup.py bdist_wheel

# Windows
py -3 setup.py bdist_wheel

This will create a file named dist/west-x.y.z-py3-none-any.whl, where x.y.z is the current version in setup.py.

To install the wheel:

pip3 install -U dist/west-x.y.z-py3-none-any.whl

You can pip3 uninstall west to remove this wheel before re-installing the version from PyPI, etc.

Installing Wheel

On macOS and Windows, you can install wheel with:

pip3 install wheel

That also works on Linux, but you may want to install wheel from your system package manager instead -- e.g. if you installed pip from your system package manager. The wheel package is likely named something like python3-wheel in that case.

west's People

Contributors

Stargazers

Watchers

Forkers

mbolivar ulfalizer maureenhelm henrikbrixandersen nashif carlescufi sathishscripts hakonfam nxp-zephyr rgundi sebastianboe tejlmand ntavish maciejjo ioannisg doanac wangnuannuan mike-scott bengartner m1cha marc-hb adfernandes next-generate xizhaojun frkv leblue machinelinux-root skelliam roprashar tliqit denve galak romlinux pengguoguo mbolivar-nordic gmarull mniestroj agileops aunsbjerg coderbyheart alexshi126 sylvioalves jsiverskog kkasperczyk-no artizirk czeslawmakarski oguedat kyberdin tagunil babyge teslabs leslieguyo duanlangtaosha sambhurst pvuchetich ashaytuc lukzeg jeffrizzo vszakd benediktibk jangalda-nsc haotian10000 mierunski phirtual umayetin johnvillalovos ryanlindemancae g-technologies-sdn-bhd liu-pingan isabella232 roufaidalaidi tomaszkob89 ccvs1993 mfkiwl memfault averseabfun tryweirdier ulrikhjort armbiant oyvindronningstad hybotics mariuszpos piao11255 zt3ph4n gimichuster mglolenstine richmetellus fabdal09 57300 konosubakonoakua argentum-systems mbolivar-ampere wmrsouza thedegeneratedev5150 karhama hzarnani kyuubi0323 joerchan arbrauns filipwithanf

west's Issues

Should "west init" run "west clone"?

Right now, installing multi-repo Zephyr takes the following steps:

$ pip install west
$ west init <west-workspace>
$ cd <west-workspace>
$ west fetch

This issue tracks whether "west init" should run "west fetch" as well after cloning west and the manifest, to eliminate the last step before a complete installation is cloned.

I am ambivalent about this idea (generally speaking I don't like to add features to the bootstrapper) but thought it was worth recording the question (and its resolution along with rationale).

Reasons for:

one less step during installation

Reasons against:

adds a feature to the bootstrapper which is not necessary
users might want to fetch with different options than can be passed to init, e.g. to fetch a subset of available projects
fetch might require different credentials than init, which might not be available at init time

ImportError: No module named 'commands'

When running west fetch, I get the following error:

from commands import CommandContextError ImportError: No module named 'commands'

Looking out on the web, i didn't found a way to install it, but ways not to use it:
yunabe/lgo#42

And according to https://bbs.archlinux.org/viewtopic.php?id=125971, "module is deprecated and should be replaced by subprocess"

Improve help text for west when not yet bootstrapped

The west bootstrapper can do a better job in providing help text to new comers.

Today west -h gives the following:

$ west -h
Error: not a Zephyr directory (or any parent): /home/<user>
Use "west init" to install Zephyr here

which isn't so helpfull, especially not, when the following is actual possible:

$ west init -h
usage: west init [-h] [-b BASE_URL] [-m MANIFEST_URL] [--mr MANIFEST_REV]
                 [-w WEST_URL] [--wr WEST_REV]
                 [directory]

Bootstrap initialize a Zephyr installation

positional arguments:
  directory             Initializes in this directory, creating it if
                        necessary

optional arguments:
  -h, --help            show this help message and exit
  -b BASE_URL, --base-url BASE_URL
                        Base URL for both 'manifest' and 'zephyr'
                        repositories; cannot be given if either -m or -w are
  -m MANIFEST_URL, --manifest-url MANIFEST_URL
                        Zephyr manifest fetch URL, default
                        https://github.com/zephyrproject-rtos/manifest
  --mr MANIFEST_REV, --manifest-rev MANIFEST_REV
                        Manifest revision to fetch, default master
  -w WEST_URL, --west-url WEST_URL
                        West fetch URL, default
                        https://github.com/zephyrproject-rtos/west
  --wr WEST_REV, --west-rev WEST_REV
                        West revision to fetch, default master

in an uninitialized folder.

Add a link in the west readme.md to the live docs

For now having a link to something like:

https://docs.zephyrproject.org/latest/west/index.html

would be useful.

Detached HEAD after initial `west fetch`

After running:

west init
west fetch

the trees are left in a detached HEAD state. The reasoning behind this according to @ulfalizer is:

west fetch only fetches data from the remote and nothing else. If the repo doesn't exist, then we need to "clone" it to get the data.
west branch creates branches that track manifest-rev in one or more repos.

The issue is that users have complained about seeing a detached HEAD after getting the tree with west. So I see 3 solutions to this:

Document this behaviour so that users understand that this is intended, and that they need to create a branch with west branch, even if that branch ends up being called master
Make west fetch create a branch (typically master) the first time it's run on an unitialized set of trees. This would essentially do:
west fetch && west branch <manifest rev> <repo>. This is a bit inconsistent with how west fetch is presented to the user.
Introduce west clone that does the initial west fetch && west branch <manifest rev> <repo>

I personally think 3) would work very well and would be very consistent with Git.

Take a fresh look at pulling rebased trees

I've been using west in a side project and noticed that west pull fails in ways that require me to provide support to users when the tree being pulled has rebased.

I think it would be nice if west could be a bit smarter about detecting if the rebase would go through cleanly and maybe stopping early and helping users decide what to do if it wouldn't, perhaps without leaving half-rebased trees around.

Kind of a vague issue at this point; I want to refine my thinking further on this.

Make launcher scripts in mainline zephyr compatible with multi- and mono-repo

The launcher scripts need to replicate the logic to find the top-level west if it exists and preferentially use that, and fall back on existing behavior to run the copy of west in zephyr/scripts/meta/west if zephyr is being checked out standalone.

This will allow a smoother interoperation of multi- and mono-repo installations of Zephyr during the transition period to multirepo.

Create new project with help of west

It would be great if west can be used to create new project. Basically it creates directory with initial template for starting new project.

Just like django-admin startproject mysite.

west should set ZEPHYR_BASE, not look for it

West knows where Zephyr is, since it parses the manifest.

This issue tracks extracting the manifest parsing code in the project command implementations into a helper module, where it can be used in the context validation code to find zephyr and set ZEPHYR_BASE in the environment before doing anything else.

Determine west-based release strategy

We mostly have a plan for tagging a west-based release as discussed in #39 (comment).

The short story is:

Tag every project (zephyr gets v1.14.0, hypothetical-other-thing gets v1.14.0, etc.)
Set the revisions for each project in the manifest file to v1.14.0; tag the commit that does that v1.14.0 as well

Then you can do west init --mr v1.14.0.

I think the thing we did not realize is that this will not prevent users from continually getting updates to west itself! These may in turn be backwards incompatible with the v1.14.0 versions of things. So if the user ever runs 'west pull', say, that will update west itself, which is not safe.

This issue tracks resolving this; it's a blocker for Zephyr v1.14.

Run a binary onto a board, d'oh

I'm using whatever west is being run with "make flash" in today's Zephyr master. So, when I run:

PYTHONPATH=/home/pfalcon/projects-3rdparty/Embedded/Zephyr/zephyr/scripts/meta /usr/bin/python3 /home/pfalcon/projects-3rdparty/Embedded/Zephyr/zephyr/scripts/meta/west/main.py flash --skip-rebuild --help

I get (among other output):

Flash and run a binary onto a board.

I don't know what "run a binary onto a board" means. That makes me concerned that I'd better flash and run it myself, I only need west to tell me how (likely will be subject of the other ticket).

west and python3.5

When running python3.5, I get the foolowing error when trying to do

pip3 install west
Traceback (most recent call last):
File "/usr/bin/pip3", line 9, in <module>
from pip import main
ImportError: cannot import name 'main'

Running with python3.6 works great.

Allow renaming default "origin" remote

Fishing for feedback with this issue. Would it be possible to allow users to rename the default remote ("origin") to whatever they like (say for example "upstream") and still be able to use west?

Improve `west --help` formatting

west --help currently renders in a format that is relatively unpleasant to the eye:

$ west --help
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V]
            {build,flash,debug,debugserver,attach,list,clone,fetch,pull,rebase,branch,checkout,diff,status,update,forall}
            ...

The Zephyr RTOS meta-tool.

optional arguments:
  -h, --help            show this help message and exit
  -z ZEPHYR_BASE, --zephyr-base ZEPHYR_BASE
                        Path to the Zephyr base directory. If not given,
                        ZEPHYR_BASE must be defined in the environment, and
                        will be used instead.
  -v, --verbose         Display verbose output. May be given multiple times to
                        increase verbosity.
  -V, --version

commands:
  {build,flash,debug,debugserver,attach,list,clone,fetch,pull,rebase,branch,checkout,diff,status,update,forall}

Run "west <command> -h" for help on each command.

Let's compare this to git, which does a much better job:

$ git --help
usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]

These are common Git commands used in various situations:

start a working area (see also: git help tutorial)
   clone      Clone a repository into a new directory
   init       Create an empty Git repository or reinitialize an existing one

work on the current change (see also: git help everyday)
   add        Add file contents to the index
   mv         Move or rename a file, a directory, or a symlink
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index

examine the history and state (see also: git help revisions)
   bisect     Use binary search to find the commit that introduced a bug
   grep       Print lines matching a pattern
   log        Show commit logs
   show       Show various types of objects
   status     Show the working tree status

grow, mark and tweak your common history
   branch     List, create, or delete branches
   checkout   Switch branches or restore working tree files
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   merge      Join two or more development histories together
   rebase     Reapply commits on top of another base tip
   tag        Create, list, delete or verify a tag object signed with GPG

collaborate (see also: git help workflows)
   fetch      Download objects and refs from another repository
   pull       Fetch from and integrate with another repository or a local branch
   push       Update remote refs along with associated objects

'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.

HttpRequestException with Private Repos

Every time west accesses a private repo and using https with a credential manager, an error is displayed, although the actual clone proceeds correctly.
Note that a pop-up window is displayed initially which seems to fail to log in the user into GitHub.

C:\Users\Carles\src>west init -u <private repo url> wncs
Initializing in new directory wncs
Cloning into 'wncs\west\west'...
remote: Enumerating objects: 38, done.
remote: Counting objects: 100% (38/38), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 792 (delta 13), reused 25 (delta 10), pack-reused 754
Receiving objects: 100% (792/792), 263.95 KiB | 1.17 MiB/s, done.
Resolving deltas: 100% (405/405), done.
Cloning into 'wncs\west\manifest'...
fatal: HttpRequestException encountered.
   An error occurred while sending the request.
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 7 (delta 0), reused 7 (delta 0), pack-reused 0
Unpacking objects: 100% (7/7), done.

west and the boostrapper should support --version flag

C:\Users\Carles\src\w>west --version
WARNING: --zephyr-base missing and no ZEPHYR_BASE in the environment
FATAL ERROR: you must specify a command
usage: west [-h] [-z ZEPHYR_BASE] [-v]
            {build,flash,debug,debugserver,attach,list-projects,fetch,pull,rebase,branch,checkout,diff,status,update,forall}
            ...

Reported by @carlescufi.

West update can leave manifest and west in unusable states

As a user, I expect that if west update fails (either run directly or as implied by west fetch or pull), that my installation is still in a usable state. However, the current implementation can leave either of these repositories in a broken (half-rebased) state if the update fails, with git merge conflict markers in source files.

To reproduce, just commit any changes that won't rebase cleanly and run west update.

The behavior instead should be to see if the rebase is possible to complete cleanly without damaging the existing installation, reporting an error if it fails with additional information on how to proceed.

Add colours on Windows with Colorama

Use colorama to support colours on Windows.

West fetch looks for manifest in wrong folder

Sep 12, the west init and west fetch worked as expected.
But from Sep 13, it appears west is looking for manifest in wrong location:

/projects/github/zephyr-west-test$ west init
Initializing in /projects/github/zephyr-west-test
Cloning into '/projects/github/zephyr-west-test/manifest'...
remote: Counting objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
Unpacking objects: 100% (13/13), done.
Checking connectivity... done.
Cloning into '/projects/github/zephyr-west-test/west'...
remote: Counting objects: 384, done.
remote: Compressing objects: 100% (87/87), done.
remote: Total 384 (delta 59), reused 58 (delta 26), pack-reused 270
Receiving objects: 100% (384/384), 128.42 KiB | 0 bytes/s, done.
Resolving deltas: 100% (199/199), done.
Checking connectivity... done.
/projects/github/zephyr-west-test$ west fetch
WARNING: --zephyr-base missing and no ZEPHYR_BASE in the environment
FATAL ERROR: Provided source_file do not exists on disk: /projects/github/zephyr-west-test/west/manifest/default.yml
run as "west -v ... fetch ..." for a stack trace
ubuntu:/projects/github/zephyr-west-test$

it looks for the manifest in:
/projects/github/zephyr-west-test/west/manifest/default.yml

where the correct location is:
/projects/github/zephyr-west-test/manifest/default.yml

Note: west fetch -m manifest/default.yml
is working

West update should be skipped if west or manifest is on a feature branch

The current auto-update behavior could use a bit of tweaking to make it more intuitive to those users who are editing their manifest or west repository and don't want to type --no-update all the time.

The issue is that it's not very convenient to switch to a manifest branch with custom changes and then issue 'west fetch', 'west pull', etc. commands, as that would try to update the manifest itself as well, which isn't what the user wants IMO. We could emulate the repo behavior instead, which is only to update the manifest itself to incorporate remote changes if the manifest repository is on the default branch tracking the remote which is created by west init.

This applies at least to the manifest, though for consistency it could be applied to west as well.

Possibly neater and simpler way of handling remotes

One thing I had somehow managed to miss all along is that Git allows URLs wherever names of remotes are allowed. You can do git fetch https://github.com/zephyrproject-rtos/zephyr.git, for example. That feature might even predate remotes, which are more like bookmarks (with some associated configuration settings, like where to store the refs that are fetched).

By always fetching directly from the URL, we could bypass the entire remote system. The nice thing about that is that we no longer rely on how remotes are configured. It's also really close to what @carlescufi wanted to see, only I thought it'd be a lot messier to implement due to remote management.

Another neat thing is that both of the following will just work (maybe they already do), with no extra work required:

[west]
remote = my-custom-remote
revision = master

[west]
remote = https://github.com/zephyrproject-rtos/west
revision = master

Any remotes we create would simply be for the user's convenience. They could even delete them or point them somewhere else, and things would still work.

Projects in the west directory are not forbidden

Originally reported by @tejlmand.

For example, even with forbidding projects named west or manifest, this manifest fragment is legal:

  projects:
    - name: not-west
      path: west

This creates a structure where the top-level west directory contains a .git for the not-west repository, which is very strange.

Arguably this is user error but the current behavior seems undesirable. We should consider what to do here:

warn
error
skip the project?
...

west docs on repo mgmt should address why something new

We're going to get a lot of questions, why not 'repo' so we should have this documented in the west docs to point people to / answer the question about why we built something ourselves.

bash autocomplete for `west`

Including bash autocompletion for west commands would immensely help the average user. This can be achieved in a very similar manner to how git does it.

west library / application / bootstrap structure and API

from the user point of view west is the go-to tool intended for repository handling, building, flashing etc.

Internally, west can be seen as:

bootstrap functionality
west library (a library which can be reused by build scripts, test, etc)
application (command line)

With the initial version, v.0.1.0 out and progress is made on v0.2.0, it is important to keep track of the future direction.

This includes, but is not limited to:

Structure and name spacing
API
What features of west do we expect other would re-use ?

West needs a configuration file infrastructure

We've discussed that west needs configuration.

Here is a proposed top-level docstring and feature description for the feature to get the conversation started:

'''West Configuration

West uses ini-style configuration files. A west configuration file is
named west.ini.

West searches for west.ini files in the following different locations,
in order:

1. Site-wide configuration directories (Linux only)

   The directories in $XDG_CONFIG_DIRS, if set, are checked for
   west.ini files in preference order (first listed has highest
   precedence, last listed has lowest).

2. Per-user configuration file(s).

   On Linux, this is $XDG_CONFIG_HOME/west/west.ini. $XDG_CONFIG_HOME
   defaults to $HOME/.config if empty or unset.

   On macOS, these are the files ~/Library/Application
   Support/west/west.ini and $HOME/.config/west/west.ini, in that
   order.

   On Windows, this is %LOCALAPPDATA%\west\west.ini.

3. Per-installation configuration file. This is the "west/west.ini"
   relative to the west installation root.

Configuration values in files that are found later take precedence
over values in earlier files. For example, per-installation
configuration files override any values in per-user configuration
files.
'''

ini sections should correspond to each command

So there would be a [build], [flash], [debug], etc section to configure the behavior of each. Examples:

[build]
# If not given on the command line, build chooses --board=nrf52_pca10040
board = nrf52_pca10040

[flash]
# If not given -- and if it is supported by the current build directory's CMake cache --
# the jlink runner would be used.
runner = jlink

library behavior is also configurable

E.g. maybe a [runner.pyocd] section to configure the behavior of that runner, like so:

[runner.pyocd]
# Override library default SWD frequency
frequency = 6000

additional configuration mechanisms

We should also provide a command-line switch and an environment variable to provide a configuration file.

E.g. west --config=my-custom.ini <COMMAND> [options], or WEST_CONFIG_FILES=my-custom-1.ini:my-custom-2.ini west <COMMAND> [options]

Runner flashing should improve address handling

The current option for inspecting the build directory to determine an address to flash a binary, --dt-flash, mixes interface and implementation and should be renamed.

It's also been pointed out in several locations that using a .hex for flashing is better than .bin when address information must be preserved anyway; we should try to deprecate uses of .bin files as much as possible.

West pull might end in detached head (unintended)

As discussed on IRC, some versions of git doesn't show reference when doing:
git --show-ref --verify HEAD
instead an error is returned, cause the local clone to go into detached head state.

git 2.7.4 is confirmed to have this behavior.
git 2.19.1 is confirmed to work as expected

See IRC discussion:

[2018-11-20 16:00:17] <tejlmand> yesterday when looking into PR#99 I noticed the behavior of `west clone`, `west fetch` and `west pull`
[2018-11-20 16:01:27] <tejlmand> for `west fetch` the help states that you go into detached head, and for `west clone` it states: 
[2018-11-20 16:01:33] <tejlmand> https://www.irccloud.com/pastebin/oBMGr9f1/
[2018-11-20 16:02:25] <tejlmand> which is also the case when doing `west clone`
[2018-11-20 16:02:28] <tejlmand> https://www.irccloud.com/pastebin/r0yPQcOs/
[2018-11-20 16:03:20] <tejlmand> but if doing `west pull` it goes into detached head;
[2018-11-20 16:07:12] <tejlmand> https://www.irccloud.com/pastebin/kTHQzn95/
[2018-11-20 16:07:32] <tejlmand> which I don't think is our intention, as the help states:
[2018-11-20 16:08:17] <tejlmand> usage: west pull [-h] [-m MANIFEST] 0 [PROJECT [PROJECT ...]]
[2018-11-20 16:08:17] <tejlmand> Clone/fetch and rebase projects.
[2018-11-20 16:08:17] <tejlmand> Fetches upstream changes in each of the specified projects (default:
[2018-11-20 16:08:17] <tejlmand> all projects) and rebases the checked-out branch (or detached HEAD
[2018-11-20 16:08:17] <tejlmand> state) on top of 'manifest-rev', effectively bringing the branch up to
[2018-11-20 16:08:17] <tejlmand> date. Repositories that do not already exist are cloned.
[2018-11-20 16:09:29] <tejlmand> what do the rest of you thinks ?
[2018-11-20 17:26:27] <Ulfalize1> tejlmand: it's a side effect of 'west pull' being 'west fetch' + 'west rebase'
[2018-11-20 20:02:19] <tejlmand> yes, and i'm asking, is that what we want ?
[2018-11-20 20:03:24] <tejlmand> cause in that case, this is not describing that behavior ` rebases the checked-out branch on top of 'manifest-rev', effectively bringing the branch up to date`
[2018-11-20 20:03:58] <tejlmand> rebasing on top of a branch shouldn't necessarily end in detached head state 
[2018-11-20 21:29:25] <Ulfalize1> don't think it's a good idea to hack around "emergent" behaviors like that too much. it makes sense given the implementation. a beautiful git example of that is how 'git rebase -i HEAD~4' allows commits in the current branch to be shuffled around, just due to how rebasing works. :)
[2018-11-20 21:30:48] <Ulfalize1> they could've added a separate command for "edit current branch", but it just happens that normal rebasing behavior solves it. thinks like that tend to happen when you don't "disallow" behaviors, i think.
[2018-11-20 21:36:54] <Ulfalize1> it's rebasing the current branch on top of a commit that's already in the branch, so the rebased part is all the commits between that commit and HEAD. the -i says you want to edit the rebased part as well.
[2018-11-20 21:37:03] <Ulfalize1> it's like code porn :P
[2018-11-20 21:39:04] <tejlmand> my main point here is that either the help text to `west pull` is wrong or the behavior
[2018-11-20 21:39:37] <tejlmand> and based on your description, you seem to think the behavior is correct, hence the help text must be wrong
[2018-11-20 21:39:43] <Ulfalize1> maybe the description could be improved. can't remember what it says. think it mentions that it's a shorthand for 'west fetch' + 'west pull' at least.
[2018-11-20 21:39:48] <tejlmand> let's wait to hear the others
[2018-11-20 21:40:28] <Ulfalize1> yeah, i think the behavior's fine. you'll get a redundant rebase if the repository isn't cloned, but that's about it.
[2018-11-20 21:42:27] <Ulfalize1> says "Clone/fetch and rebase projects" and "repositories that do not already exist are cloned"
[2018-11-20 21:42:55] <Ulfalize1> guess it could also mention that it's just 'west fetch' + 'west rebase'
[2018-11-20 21:43:01] <Ulfalize1> but seems to mention it already at least
[2018-11-20 21:43:27] <Ulfalize1> anyway, back to DT land
[2018-11-20 21:48:04] <Ulfalize1> ('git pull' is a shorthand for 'git fetch' + 'git rebase' btw, when pull.rebase is true. otherwise, it's a shorthand for 'git fetch' + 'git merge'.)
[2018-11-20 21:51:02] <tejlmand> but a rebase still doesn't need to end up in a detached head
[2018-11-20 21:51:17] <tejlmand> it it does so, it should be mentioned
[2018-11-20 21:51:24] <Ulfalize1> it does if you're in a detached head state to begin with
[2018-11-20 21:51:34] <tejlmand> just as it is mentioned in `west clone -h`
[2018-11-20 21:51:37] <Ulfalize1> 'west rebase' won't give you a detached head if you're on a branch
[2018-11-20 21:51:41] <Ulfalize1> if it does, that's a bug
[2018-11-20 21:51:50] <tejlmand> i'm not in detached head to begin with.
[2018-11-20 21:51:53] <tejlmand> I do:
[2018-11-20 21:51:58] <tejlmand> `west init`
[2018-11-20 21:52:02] <tejlmand> `west clone`
[2018-11-20 21:52:10] <tejlmand> `west pull`
[2018-11-20 21:52:31] <tejlmand> and then I ended in detached head, but no changes between `clone` and `pull`
[2018-11-20 21:52:42] <Ulfalize1> hmm, lemme check
[2018-11-20 21:52:46] <tejlmand> `west clone` does not end in detached head
[2018-11-20 21:54:59] <Ulfalize1> what do you get if you run  west init + west clone + west rebase?
[2018-11-20 21:55:15] <Ulfalize1> also, are you cloning everything?
[2018-11-20 21:58:32] <tejlmand> `=== zephyr (zephyr/) is up-to-date with manifest-rev`
[2018-11-20 21:58:56] <tejlmand> so `west rebase` changes nothing
[2018-11-20 21:59:05] <tejlmand> which was also my expectation
[2018-11-20 21:59:07] <Ulfalize1> try running a 'west fetch' too
[2018-11-20 21:59:26] <tejlmand> what i'm doing, is basically just a normal expected workflow
[2018-11-20 21:59:36] <tejlmand> `west init` to get started
[2018-11-20 21:59:44] <Ulfalize1> the only thing i can think of that could give a detached HEAD there is the code around 'if not _ref_ok(project, 'HEAD'):' in _fetch() (in project.py)
[2018-11-20 21:59:45] <tejlmand> `west clone` to work on Zephyr
[2018-11-20 22:00:02] <Ulfalize1> yeah, you shouldn't get a detached head. trying to debug. :)
[2018-11-20 22:00:08] <Ulfalize1> because i've never seen it
[2018-11-20 22:00:15] <tejlmand> `west pull` to update my zephyr, and sometimes there might be no changes, like now
[2018-11-20 22:00:17] <Ulfalize1> try a 'west fetch' and see if that messes anything up
[2018-11-20 22:00:23] <tejlmand> will do
[2018-11-20 22:01:06] <tejlmand> `west fetch` gets me into detached head
[2018-11-20 22:01:30] <tejlmand> `west rebase` afterwards just tells everything is up-to-date
[2018-11-20 22:01:35] <Ulfalize1> something is wonky with the _ref_ok() check in that case
[2018-11-20 22:01:51] <tejlmand> but stays in detached head (which is expected, when already being in that state)
[2018-11-20 22:02:06] <Ulfalize1> try doing a 'west clone', and then running 'git show-ref --quiet --verify HEAD' inside one of the repositories
[2018-11-20 22:02:25] <Ulfalize1> check the return status. could try removing the --quiet too.
[2018-11-20 22:03:02] <tejlmand> currently only Zephyr in the default manifest :p
[2018-11-20 22:03:25] <Ulfalize1> yeah, would be nice if we added at least one more...
[2018-11-20 22:03:36] <Ulfalize1> shouldn't matter here at least
[2018-11-20 22:05:08] <Ulfalize1> the fetch code runs that git command to check if the repository has just been initialized, with nothing checked out. looks like it's failing for some reason for you.
[2018-11-20 22:05:11] <tejlmand> `$ git show-ref --verify HEAD`
[2018-11-20 22:05:11] <tejlmand> `fatal: 'HEAD' - not a valid ref`
[2018-11-20 22:05:11] <tejlmand> `$ echo $?`
[2018-11-20 22:05:11] <tejlmand> `128`
[2018-11-20 22:06:21] <tejlmand> `$ git --version`
[2018-11-20 22:06:21] <tejlmand> `git version 2.7.4`
[2018-11-20 22:06:57] <Ulfalize1> does 'git show-ref --head --verify HEAD' work?
[2018-11-20 22:07:54] <tejlmand> nope
[2018-11-20 22:07:56] <tejlmand> same error
[2018-11-20 22:08:16] <Ulfalize1> what does  ls .git  list?
[2018-11-20 22:08:30] <tejlmand> but `git show-ref --head`
[2018-11-20 22:08:40] <tejlmand> give a lot, but most interresting:
[2018-11-20 22:09:19] <tejlmand> `$ git show-ref --head`
[2018-11-20 22:09:19] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 HEAD`
[2018-11-20 22:09:19] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 refs/heads/manifest-rev`
[2018-11-20 22:09:19] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 refs/heads/master`
[2018-11-20 22:09:19] <tejlmand> `576bb63a6401befa0d24f33919ccd965d1ba8ce5 refs/tags/v1.0.0`
[2018-11-20 22:09:19] <tejlmand> `...`
[2018-11-20 22:10:18] <tejlmand> as expected I would say
[2018-11-20 22:10:18] <Ulfalize1> ok, so it's in there at least
[2018-11-20 22:10:30] <tejlmand> '$ ls .git`
[2018-11-20 22:10:30] <tejlmand> `branches config description FETCH_HEAD HEAD hooks index info logs objects refs`
[2018-11-20 22:10:40] <tejlmand> including `HEAD`
[2018-11-20 22:10:53] <Ulfalize1> yeah, just need to find a command that detects a valid HEAD with that git version
[2018-11-20 22:11:56] <Ulfalize1> the point of the check is that just after 'git init' + 'git fetch', HEAD won't be a valid ref (it'll point to a non-existent branch). in that case, a detached head is checked out at manifest-rev.
[2018-11-20 22:12:01] <Ulfalize1> but the check seems broken on your git version
[2018-11-20 22:12:20] <Ulfalize1> so it thinks you're still in the 'git init' state, and checks out a detached head
[2018-11-20 22:13:33] <tejlmand> withour verify it works
[2018-11-20 22:13:41] <tejlmand> `$ git show-ref --head HEAD`
[2018-11-20 22:13:41] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 HEAD`
[2018-11-20 22:14:48] <tejlmand> is verify strictly needed ?
[2018-11-20 22:14:57] <tejlmand> `--verify`
[2018-11-20 22:14:57] <tejlmand> `Enable stricter reference checking by requiring an exact ref path. Aside from returning an error code of 1, it will also print an error message if --quiet was not specified.`
[2018-11-20 22:15:38] <tejlmand> if we have the sha from FETCH_HEAD also, we can simply compare them
[2018-11-20 22:15:42] <Ulfalize1> for some reason i get the wrong ref if i don't include it
[2018-11-20 22:15:49] <Ulfalize1> 1ce80e0fe98e72af4125f47c65b0bc01b60a7feb refs/remotes/origin/HEAD
[2018-11-20 22:15:52] <tejlmand> :s
[2018-11-20 22:15:53] <Ulfalize1> and no HEAD at all
[2018-11-20 22:16:04] <tejlmand> guess we have something to look into here
[2018-11-20 22:16:14] <tejlmand> which git version are you using ?
[2018-11-20 22:16:21] <Ulfalize1> 2.19.1
[2018-11-20 22:16:37] <tejlmand> btw. now I assume you understand the reason for my initial question ;p
[2018-11-20 22:16:46] <Ulfalize1> could you try playing around a fresh 'git init' repository and a "normal" repository and seeing if you can find a command that checks if HEAD is valid?
[2018-11-20 22:16:46] <tejlmand> ;) of course
[2018-11-20 22:17:08] <Ulfalize1> yeah, that was never intended behavior. thought you were starting in a detached head state. :P
[2018-11-20 22:17:08] <tejlmand> sure, but that will be tomorrow morning.wife is calling :D
[2018-11-20 22:17:42] <Ulfalize1> ok, no worries. something that fails for the 'git init' case and works otherwise is what we want at least.
[2018-11-20 22:17:52] <Ulfalize1> that show-ref thingy works on my git version. something must've changed.
[2018-11-20 22:18:16] <tejlmand> will also try updating git
[2018-11-20 22:18:24] <Ulfalize1> just keep the old git version around for testing ;)
[2018-11-20 22:18:33] <tejlmand> just to see if there is a behavior change that we should pay attention to
[2018-11-20 22:18:39] <tejlmand> of course
[2018-11-20 22:18:57] <tejlmand> will have them side-by-side
[2018-11-20 22:19:39] <Ulfalize1> try 'git rev-parse' too (https://stackoverflow.com/questions/34628532/git-how-to-determine-if-a-ref-to-a-commit-exists)
[2018-11-20 22:19:44] <Ulfalize1> suspect that might work
[2018-11-21 07:07:42] ⇐ tejlmand quit (uid304420@gateway/web/irccloud.com/x-qpetbzbimyczhzrg): Quit: Connection closed for inactivity
[2018-11-21 07:07:42] * Connection closed for inactivity
[2018-11-21 07:07:42] * Socket closed
[2018-11-21 08:27:52] → Joined channel #zephyr-meta
[2018-11-21 08:27:52] * Channel mode is +ns
[2018-11-21 09:11:44] <tejlmand> tried with both 2.7.4 and 2.19.1
[2018-11-21 09:13:28] <tejlmand> 2.7.4
[2018-11-21 09:13:28] <tejlmand> `$ git show-ref --head --verify HEAD`
[2018-11-21 09:13:28] <tejlmand> `fatal: 'HEAD' - not a valid ref`
[2018-11-21 09:13:28] <tejlmand> `$ git show-ref --head HEAD`
[2018-11-21 09:13:28] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 HEAD`
[2018-11-21 09:13:28] <tejlmand> 2.19.1
[2018-11-21 09:13:28] <tejlmand> `$ /opt/git-2.19.1/bin/git show-ref --head --verify HEAD`
[2018-11-21 09:13:28] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 HEAD`
[2018-11-21 09:13:28] <tejlmand> `$ /opt/git-2.19.1/bin/git show-ref --head HEAD`
[2018-11-21 09:13:28] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6 HEAD`
[2018-11-21 09:14:57] <Ulfalizer> tejlmand: thanks! could you try with rev-parse too?
[2018-11-21 09:15:37] <Ulfalizer> problem with 'git show-ref --head HEAD' is that it also shows remotes branches that happen to be called HEAD
[2018-11-21 09:15:42] <Ulfalizer> can get those in practice sometimes
[2018-11-21 09:20:38] <tejlmand> `$ git rev-parse --verify HEAD`
[2018-11-21 09:20:38] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6`
[2018-11-21 09:20:38] <tejlmand> `$ /opt/git-2.19.1/bin/git rev-parse --verify HEAD`
[2018-11-21 09:20:38] <tejlmand> `5f09eae7a16d95857225b9fc7da948ee80fd27e6`
[2018-11-21 09:23:19] <Ulfalizer> nice, will probably work then :)

west checkout -b should respect my current HEAD

If I manually make some commits in a random branch across multiple projcts, then run west checkout -b NEWBRANCH, I expect NEWBRANCH to point at my current repository HEADs. However, it points at manifest-rev instead, making the behavior more like git checkout -b NEWBRANCH manifest-rev than git checkout -b NEWBRANCH.

This is confusing and annoying as now I have to go back and reset the new branches to where I wanted them to be in the first place.

Detached HEAD when tracking a branch

With a simple manifest that just tracks the master (or any other) branch of the repos included, I do not see why we have to end up with a detached HEAD upon running west init and west fetch. It would make sense to me to end up with a local branch checked out that matches the name of the remote tracking branch instead of HEAD detached at refs/heads/manifest-rev

SyntaxError: invalid syntax when calling west

nuc01:~: cd multirepo/
nuc01:multirepo: ls
manifest  west
nuc01:multirepo: ls -la
total 0
drwxrwxr-x. 1 nashif nashif  34 Sep  3 14:36 .
drwx------. 1 nashif nashif 690 Sep  3 14:36 ..
drwxrwxr-x. 1 nashif nashif  50 Sep  3 14:36 manifest
drwxrwxr-x. 1 nashif nashif   0 Sep  3 14:36 .west
drwxrwxr-x. 1 nashif nashif 216 Sep  3 14:36 west
nuc01:multirepo: west
Traceback (most recent call last):
  File "/usr/bin/west", line 11, in <module>
    load_entry_point('west==0.2.5', 'console_scripts', 'west')()
  File "build/bdist.linux-x86_64/egg/bootstrap/main.py", line 188, in main
  File "build/bdist.linux-x86_64/egg/bootstrap/main.py", line 173, in wrap
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/nashif/multirepo/west/src/west/main.py", line 15, in <module>
    from . import log
  File "/home/nashif/multirepo/west/src/west/log.py", line 33
    def dbg(*args, level=VERBOSE_NORMAL):
                       ^
SyntaxError: invalid syntax

Need a way for west to output flash, etc. commands for me

Please see #112 for not very relevant, but at least some context. The message conveyed there is "by various reasons, I don't trust various wrapper tools, and prefer to run my commands myself".

So, I came to this:

$ PYTHONPATH=/home/pfalcon/projects-3rdparty/Embedded/Zephyr/zephyr/scripts/meta /usr/bin/python3 /home/pfalcon/projects-3rdparty/Embedded/Zephyr/zephyr/scripts/meta/west/main.py -v flash --skip-rebuild
Using runner: jlink
Flashing Target Device
JLinkExe -if swd -speed auto -device MCIMXRT1052 -CommanderScript /tmp/tmp868see73jlink/runner.jlink
FATAL ERROR: 2 No such file or directory: 'JLinkExe'
Traceback (most recent call last):
  File "/home/pfalcon/projects-3rdparty/Embedded/Zephyr/zephyr/scripts/meta/west/main.py", line 193, in <module>
    main()
...

So, the -v would seem to be just what I need, but of course after it quits, /tmp/tmp868see73jlink/runner.jlink doesn't any longer exist.

So, would need some kind of --dry-run option, which would just output commands to run, didn't run them, but created and left in place any dependent files. Thanks.

Missing dependencies when installing west

I had to fetch following python modules following west install:
-log
-public (had to use pip install public==0.0.46 to get it)

Allow multiple URLs for a project

Remotes are specified in the manifest as:

remotes:
- name: zephyrproject-rtos
url: https://github.com/zephyrproject-rtos
or
remotes:
- name: zephyrproject-rtos
url: [email protected]:zephyrproject-rtos/zephyr.git
but there cannot be two url for one remote.

the https version is easy to start out with, but often ssh with keys are nicer to work with (imho).

Could it be made possible to maybe be able to specify some like:
remotes:
- name: zephyrproject-rtos
url: https://github.com/zephyrproject-rtos
url-ssh: [email protected]:zephyrproject-rtos/zephyr.git
the type specified under url is used per default but if url-ssh is present and users specify, e.g.
west fetch --ssh
uses url-ssh if present (otherwise fallback is url)

Feature idea: "west bisect"

This feature idea is inspired by the "git bisect" feature, which can do a form of binary search on a topological sort of the commit DAG to find a commit which introduces an issue or changed behavior.

In a multi-repo setup, it is no longer possible to git bisect within a single repository, of course. However, it does become possible to bisect entire configurations of the multi-repo. This issue is a place to discuss how we might accomplish that.

In Google repo terms, a "frozen manifest" is a manifest file where every revision is an exact SHA. It is a common practice in some repo-based environments to save frozen manifests as part of the artifacts in a build server or CI environment. The sequence of such manifests can be bisected to find a first "bad build" to check the individual changes in each repository from the last "good build".

If you have a manifest repository branch that contains a history of frozen manifest files, you could imagine running git bisect there, checking out the SHAs at each step, and having that be the input to decide the "bad/goodness" of.

A more interesting but far-fetched and less tractable idea would be to tell west directly a good and bad frozen manifest -- e.g. west bisect good SHA1 PROJECT1 SHA2 PROJECT2 [...], and west bisect bad [...] etc., then west would try to bisect among multiple repositories.

I think that is less tractable because git history being a DAG implies the existence of at least one total order on the commits that "makes sense" -- any topsort is such a total order. I'm not sure we can do the same with multiple repositories.

So perhaps if Zephyr's own CI starts to create nightly frozen manifests and publishing them to a branch, we might have a useful starting point.

Better recovery from aborted `west fetch`

From a comment in #75:

    # TODO: Check if the repository is in the post-'git init' state instead.
    # That allows repositories to be properly initialized even if the initial
    # 'west fetch' is aborted and then resumed.

This enhancement issue tracks resolving that.

West should not hide backtraces for internal errors

West currently catches all exceptions in main.py and prints just the exception message, telling users to pass -v to see the full backtrace.

The issue with this is that if an exception is raised due to a problem with the code, then the backtrace is useful information. Removing it is counterproductive, especially if the problem can't be easily reproduced.

Another issue is that it mixes up expected and unexpected exceptions. For expected exceptions, they ought to be turned into friendly output closer to the point where they're generated, instead of throwing an exception all the way up to main.py. We already do this with log.die() and the like.

Note that I'm not saying that all exceptions should generate backtraces. Just the unexpected exceptions should. Expected errors should be handled where they're generated, and turned into friendlier output there.

unresolved PyYAML dependencies

not sure what to do about that...

nuc01:multirepo: west
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 570, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 888, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 779, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (PyYAML 3.12 (/usr/lib64/python3.6/site-packages), Requirement.parse('PyYAML==3.11'), {'pykwalify'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nashif/.local/bin/west", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3095, in <module>
    @_call_aside
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3079, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3108, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 572, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 585, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 779, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (PyYAML 3.12 (/usr/lib64/python3.6/site-packages), Requirement.parse('PyYAML==3.11'), {'pykwalify'})

west should be able to list boards

If we do something like:

$ west build --board
usage: west build [-h] [-b BOARD] [-s SOURCE_DIR] [-d BUILD_DIR] [-t TARGET]
                  [-c] [-f]
                  [cmake_opt [cmake_opt ...]]
west build: error: argument -b/--board: expected one argument

Would be nice if west could list the boards available.

`west init` bootstrapping and manifest revision

Implementing PR#99 revealed that the way west and manifest is cloned might cause unintended side-effect when implementing re-init functionality using west init.

See discussion here: #99 (comment)

West fetch/clone/pull/etc should fetch tags

The project commands which pull code from upstream repositories only fetch the history named in the revision. That's okay, but they don't fetch any tags, even if those tags are part of that history.

That's a problem and should be fixed.

print remotes with `list-projects`

The list-projects command currently doesn't print the remotes. It would be good to be able to list the remotes, even if it's with an additional param.

West crashes if default.yml doesn't exist

Looks like there's some new stuff in set_zephyr_base() that's causing it:

Traceback (most recent call last):
  File "/home/ulf/trywest/west/west/src/west/main.py", line 229, in <module>
    main()
  File "/home/ulf/trywest/west/west/src/west/main.py", line 201, in main
    args, unknown = parse_args(argv)
  File "/home/ulf/trywest/west/west/src/west/main.py", line 184, in parse_args
    set_zephyr_base(args)
  File "/home/ulf/trywest/west/west/src/west/main.py", line 90, in set_zephyr_base
    manifest = Manifest.from_file()
  File "/home/ulf/trywest/west/west/src/west/manifest.py", line 52, in from_file
    return Manifest(source_file=source_file)
  File "/home/ulf/trywest/west/west/src/west/manifest.py", line 81, in __init__
    with open(source_file, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/ulf/trywest/west/manifest/default.yml'

NameError: global name 'PermissionError' is not defined

nuc01:~: west init /tmp/xxx
('Initializing in new directory', '/tmp/xxx')
Traceback (most recent call last):
  File "/usr/bin/west", line 11, in <module>
    load_entry_point('west==0.2.5', 'console_scripts', 'west')()
  File "build/bdist.linux-x86_64/egg/bootstrap/main.py", line 190, in main
  File "build/bdist.linux-x86_64/egg/bootstrap/main.py", line 127, in init
  File "build/bdist.linux-x86_64/egg/bootstrap/main.py", line 136, in init_bootstrap
NameError: global name 'PermissionError' is not defined

West update should update to remote branches passed to west init

Currently, west update unconditionally rebases onto remotes/origin/master.

This is inconsistent with the ability of the user to pass arbitrary manifest and west revisions to west init. As a user, I expect that west will track the remote revisions I passed it, especially if they were branches.

(If they were tags or SHAs, I believe that as a user I would expect west update to be a no-op, but I haven't thought about it enough to be sure.)

This issue tracks fixing the problem, so that west update works as expected.

Add menuconfig to the list of west commands

Similar to flash and debug, add menuconfig.

Not possible to checkout remote branch using west.

west tool fails when trying to checkout remote branch using:
west checkout v1.13-branch zephyr
fails with error:
FATAL ERROR: No branch v1.13-branch exists in any of the listed projects

This is done after west init and west fetch

Note: Doing this manually with git of course works:
cd zephyr/
zephyr$ git checkout v1.13-branch
Branch v1.13-branch set up to track remote branch v1.13-branch from origin.

west flash displays spurious ninja message

When running west flash one sees a spurious ninja: no work to do. message

$ west flash
ninja: no work to do.
Using runner: nrfjprog
Flashing file: /home/carles/src/wncs/zephyr/samples/bluetooth/beacon/build/zephyr/zephyr.hex
Parsing hex file.
Erasing page at address 0x0.
Erasing page at address 0x1000.
Erasing page at address 0x2000.
Erasing page at address 0x3000.
Erasing page at address 0x4000.
Erasing page at address 0x5000.
Erasing page at address 0x6000.
Erasing page at address 0x7000.
Erasing page at address 0x8000.
Erasing page at address 0x9000.
Erasing page at address 0xA000.
Erasing page at address 0xB000.
Erasing page at address 0xC000.
Erasing page at address 0xD000.
Erasing page at address 0xE000.
Erasing page at address 0xF000.
Erasing page at address 0x10000.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Enabling pin reset.
Applying pin reset.
Board with serial number 682411272 flashed successfully.

West should support reinitializing an existing installation

We've always left a hole in west's init_reinit() routine, which is what gets run when a user attempts to west init an existing west installation. Right now, it simply reports an error.

With the new configuration file infrastructure (#75), we should have all the pieces to reinitialize now:

west repository
manifest repository
configuration directory with new west and manifest revisions
west marker file

Once those are reinitialized, the next west fetch should pull down the updated configuration specified by the above without any extra work or changes.

List tags of remote manifest using west

west is the future starting point when working with Zephyr and projects based on Zephyr.

It is intended both for skilled developers to facilitate working with features crossing multiple repos, so that PR's can easier be managed.

But west is also the starting point for less experienced developers or developers unfamiliar with git.
And an clear way of relating multiple repo.

To initialize west and fetch latest zephyr, one will do:

west init
west fetch

and if one wants a dedicated revision, the following can be used:

west init --mr <revision>

However, if user want to see available revision on the manifest, he would need to write:

git ls-remote --tags --refs https://github.com/zephyrproject-rtos/manifest

What would be nice, is to tag the manifest when a new release is made, e.g. v1.14, v1.15, etc on the manifest.

Then documentation can be:

Using zephyr latest version:
west init
west fetch

To see list of Zephyr releases, and fetch a given version:
west init --lr   <-- Other name can be proposed, functionaliy is important
west init --mr <revision>
west fetch

This gives a user a clear ways to find what releases are available, it makes it easier for Zephyr and companies forking Zephyr to distribute multiple releases though the manifest.

And as the process is very clear, it is also very easy to describe.