The west package contains type annotations, but mypy doesn't know
about them because of a missing metadata file. This prevents us from
type-checking calls into the west APIs, which we should be able to do.
Add the necessary metadata to make this work.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Upstream Zephyr has moved to python v3.8 as a minimum version, so it's
OK for west to move too. Make that happen.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
West has historically relied on the third-party configobj library for
writing configuration files instead of using the standard library's
configparser module. The reason why is that configobj has round-trip
support for comments.
However, the public reading API uses configparser. Up until now, we
were assuming that the two were compatible for the simple purposes we
needed, and indeed they've proven compatible "enough" that the
different code paths on read vs. write haven't been an issue.
This has become a problem now that we are introducing the
manifest.groups configuration option, though, because its value
contains commas. The configparser and configobj file formats have a
semantic difference between these two options, though:
[section]
foo = "one,two"
bar = one,two
The difference is:
- in configobj, 'foo' is the string "one,two" and 'bar' is the list
['one', 'two']
- in configparser, 'foo' is the string '"one,two"' and bar is the string
'one,two'
Further, the configobj library automatically adds quotes around any
string that contains commas to enforce this distinction.
This is breaking round-trips, since:
west config section.foo one,two # configobj writes "one,two"
west config section.foo # configparser reads '"one,two"'
Looking at it further, configobj development seems to have stalled in
2014, and the most significant user it claims in its
documentation (IPython) has moved on to .py and .json configuration
files.
This isn't worth the hassle. Just drop the configobj dependency and
use configparser everywhere. This will delete comments that users have
added to their configuration files and may otherwise reorder sections,
but having the round-trip semantics correct is more important than
that.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
this adds support for running python ~/path/to/west/setup.py develop
from other directories.
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
This relates to issue #38, the TL;DR of which is that we've never
gotten around to properly separating west's application internals from
its API in source code, and instead relied on documentation to spell
out exactly what the API was that users could rely on.
Let's start fixing that by moving everything users can't rely on into
a new west.app. This includes everything in west.commands except the
__init__ module, so we can just make that a new src/west/commands.py
file and have it be a module instead of a package. This lets its
pykwalify schema file, west-commands-schema.yml, sit next to it in
src/west, which is flatter than before.
The code changes in this commit (source lines changed, rather than
files just getting moved around) are:
- change the entry point in setup.py to west.app.main:main
- change some imports in src/west/app/main.py to import from
west.app instead of west.commands
- add a new src/west/app/__init__.py, since we're not using
namespace packages
- changes in MANIFEST.in and test_help.py to reflect new paths
- adjust some comments and docstrings
This change makes the API divide clearer. This in turn exposes some
problems with our use of west.log from west.manifest:
1. logging to stdout is a bad practice from a library
2. west.log also uses global state (which relates to #149 also)
which non-command-line users won't have set up properly
(this is an example of why #1 is true)
Subsequent commits will move to only using west.log from within
west.app.* and the existing deprecated west.build and west.cmake APIs,
which users should be migrating away from anyway.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We used to require the use of namespace packages, because west was
split into a bootstrapper and per-installation clone. That hasn't been
true since 0.6.0, so stop treating west like a namespace package.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Use the as_yaml() and as_frozen_yaml() convenience functions,
which is safe to do now that we don't get an OrderedDict out of
west.manifest.as_dict() and friend.
This requires PyYAML 5.1 or later.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
West 0.7.0 will require Python 3.6, just like Zephyr 2.2 will.
Move to the zephyrproject-rtos/ci container which contains this
Python. This has the ancillary benefit of making this test environment
the same as Zephyr's.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
As we evolve the manifest data, we want to be able to enforce a
minimum version of west required to parse it. Add an optional
'version' key to the data to make this possible.
We have to validate this before checking the manifest against the
schema, as later versions of west will likely extend the schema in
ways that would raise errors if we used our schema to check the data.
We allow the version to be parsed as a YAML float (like 1.0) and
convert it to a string as a convenience for the user.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
This allows uploading vX.Y.Z.devN development snapshots to PyPI as
needed, without having to touch version.py or go through the pull
request process.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
This is needed for find_namespace_packages. Make sure CI upgrades it
as well; the default shippable container doesn't meet the requirement.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Get rid of the separate bootstrapper. Implement 'west init' as a
regular WestCommand which combines the bootstrapper + PostInit.
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>
Put the version into src/west/_bootstrap/version.py, and extract it in
setup.py. This will allow us to inspect it in the bootstrapper and
west itself.
For details, see: https://packaging.python.org/guides/single-sourcing-package-version/#single-sourcing-the-version
This option was chosen from the many given there mainly because it
worked cleanly with west's split into bootstrapper and "main" pieces.
Fixes#45
Signed-off-by: Marti Bolivar <marti@foundries.io>
This accomplishes two goals:
1. cleans up the installation namespace by installing all west-related
code into a 'west' namespace package
2. allows us a somewhat clean way to share a version specifier among
the bootstrapper, west itself, and setup.py
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 use of requirements.txt is resulting in an incorrectly packaged
source distribution (sdist) for west. This is because while setup.py
is copied into the sdist archive, requirements.txt is not, so using
"pip install <sdist>.tar.gz" fails like so (shown with the 0.1.0
sdist):
$ wget 77593677335ba03c2b7122c07c5b4d/west-0.1.0.tar.gz
$ pip install west-0.1.0.tar.gz
[...]
FileNotFoundError: [Errno 2] No such file or directory: 'requirements.txt'
[...]
I didn't notice this when uploading 0.1.0 because pip prefers to
install wheels over sdists, our 0.1.0 wheel works, and I never tested
installing the sdist.
Further review of the way requirements.txt is meant to be used
(https://packaging.python.org/discussions/install-requires-vs-requirements/)
seems to indicate that the two are not meant to be used together.
Work towards fixing the sdist by inlining the requirements.txt
contents into setup.py. (Another issue with tests_requirements.txt is
next).
Signed-off-by: Marti Bolivar <marti@foundries.io>
Similarly to how Zephyr indicates the next development version with a
.99 patch level, update west so it's clear this is post-0.1.0.
Signed-off-by: Marti Bolivar <marti@foundries.io>
A tuple was originally used to indicate that the variable was
immutable, but this generates a warning on python 3.7; setuptools
really wants a list.
Signed-off-by: Marti Bolivar <marti@foundries.io>
As discussed internally, we're ready to push this to the 'real'
PyPI (not Test PyPI) now. The version has been incremented several
times previously during testing uploads on Test PyPI. This is no
longer necessary, so set it to the real semantic version we desire for
this stage, which is 0.1.0.
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>
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>
Martí Bolívar