Add 'path-prefix' key in west import map #367
Comments
|
LGTM. Personally I prefer |
|
Directory is fine fo me too |
|
I'd love to see this implemented also ! I'll take whatever keyword I get for 'directory', but also consider some alternatives:
(Having 'prefix' or 'base' in there appeals to me because the actual destination is the path+name) |
Agreed, "directory" or "path" are super generic terms, way too vague when left alone. Inspired by "destination" and trying to describe the action rather than the elusive nature, how about By the way will this new prefix support more than one multiple directory level? |
It should IMO. |
|
+1 for "into" Let me know if I can help somehow. |
|
I would like to have something like this. But I would prefer a syntax that adds a prefix to the defaults section of the manifest: defaults:
path_prefix: prefix_pathMy goal at this moment is to have only the projects I´m using by setting import as false. |
|
Just a thought. and now you suddenly add mixing In this case, And we would end up with: |
While I find path and directory both too generic, I think the difference between them is well defined: a path is (long story short) a list of nested directories. This definition is surprisingly consistent across languages: Hence my earlier question about supporting multiple levels. |
I was more referring to the situation in the original proposal where the yaml could look as: in this case I personally fail to see why then it seems to my the |
|
This seems like a gap with west now -- looking forward to this issue being resolved by a PR. |
mbolivar-nordic
changed the title
Several users have requested the ability to place a project and its
imports in a designated subdirectory to keep third party code
separated from user-written code. Add this feature using a new key in
an import: map.
Example syntax:
manifest:
projects:
- name: zephyr
url: https://github.com/zephyrproject-rtos/zephyr
import:
path-prefix: zephyr_projects
Semantics:
- the zephyr project, and all imported projects, have zephyr_projects
as an additional path component. e.g. zephyr_projects/zephyr instead
of zephyr as the path for zephyr project
- the path-prefix value cannot escape the workspace, e.g.
path-prefix: ../.. would be an error in the above example.
- the 'path-prefix' value is "cumulative" across imports, e.g.
if the imported manifest in turn does an import with "path-prefix: foo",
the combined directory is "zephyr_projects/foo"
We've already laid most of the groundwork for plumbing this through
the import handling code using the _import_ctx and _import_map
namedtuples. When recursively loading Manifest instances during import
resolution, _import_ctx is a container that allows us to pass
information obtained from "higher" manifests down to "lower" manifests
in the tree. The _import_map namedtuple is just a container for the
import: contents when its value is a dict.
What remains to be done is then to add the current "cumulative" path
prefix to _import_ctx and pass it around to a couple of additional
places where it wasn't previously needed but now is. This requires
generalizing _new_ctx() a bit so we can combine an existing context
with the entire _import_map at a particular "import:" instead of just
using its filter function like we do now.
The one edge case is that since path-prefix affects the "imported"
project itself (zephyr in the above example), we need to make sure to
load it when creating every Project instance. This means we
effectively do it twice, which is a bit wasteful but keeps the code
simple, so it's worthwhile waste.
Fixes: zephyrproject-rtos#367
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Several users have requested the ability to place a project and its
imports in a designated subdirectory to keep third party code
separated from user-written code. Add this feature using a new key in
an import: map.
Example syntax:
manifest:
projects:
- name: zephyr
url: https://github.com/zephyrproject-rtos/zephyr
import:
path-prefix: zephyr_projects
Semantics:
- the zephyr project, and all imported projects, have zephyr_projects
as an additional path component. e.g. zephyr_projects/zephyr instead
of zephyr as the path for zephyr project
- the path-prefix value cannot escape the workspace, e.g.
path-prefix: ../.. would be an error in the above example.
- the 'path-prefix' value is "cumulative" across imports, e.g.
if the imported manifest in turn does an import with "path-prefix: foo",
the combined directory is "zephyr_projects/foo"
We've already laid most of the groundwork for plumbing this through
the import handling code using the _import_ctx and _import_map
namedtuples. When recursively loading Manifest instances during import
resolution, _import_ctx is a container that allows us to pass
information obtained from "higher" manifests down to "lower" manifests
in the tree. The _import_map namedtuple is just a container for the
import: contents when its value is a dict.
What remains to be done is then to add the current "cumulative" path
prefix to _import_ctx and pass it around to a couple of additional
places where it wasn't previously needed but now is. This requires
generalizing _new_ctx() a bit so we can combine an existing context
with the entire _import_map at a particular "import:" instead of just
using its filter function like we do now.
The one edge case is that since path-prefix affects the "imported"
project itself (zephyr in the above example), we need to make sure to
load it when creating every Project instance. This means we
effectively do it twice, which is a bit wasteful but keeps the code
simple, so it's worthwhile waste.
Fixes: zephyrproject-rtos#367
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Several users have requested the ability to place a project and its
imports in a designated subdirectory to keep third party code
separated from user-written code. Add this feature using a new key in
an import: map.
Example syntax:
manifest:
projects:
- name: zephyr
url: https://github.com/zephyrproject-rtos/zephyr
import:
path-prefix: zephyr_projects
Semantics:
- the zephyr project, and all imported projects, have zephyr_projects
as an additional path component. e.g. zephyr_projects/zephyr instead
of zephyr as the path for zephyr project
- the path-prefix value cannot escape the workspace, e.g.
path-prefix: ../.. would be an error in the above example.
- the 'path-prefix' value is "cumulative" across imports, e.g.
if the imported manifest in turn does an import with "path-prefix: foo",
the combined directory is "zephyr_projects/foo"
We've already laid most of the groundwork for plumbing this through
the import handling code using the _import_ctx and _import_map
namedtuples. When recursively loading Manifest instances during import
resolution, _import_ctx is a container that allows us to pass
information obtained from "higher" manifests down to "lower" manifests
in the tree. The _import_map namedtuple is just a container for the
import: contents when its value is a dict.
What remains to be done is then to add the current "cumulative" path
prefix to _import_ctx and pass it around to a couple of additional
places where it wasn't previously needed but now is. This requires
generalizing _new_ctx() a bit so we can combine an existing context
with the entire _import_map at a particular "import:" instead of just
using its filter function like we do now.
The one edge case is that since path-prefix affects the "imported"
project itself (zephyr in the above example), we need to make sure to
load it when creating every Project instance. This means we
effectively do it twice, which is a bit wasteful but keeps the code
simple, so it's worthwhile waste.
Fixes: #367
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Example syntax:
Semantics:
zephyrproject, and all imported projects, havezephyr_projectsas an additional path component. e.g.zephyr_projects/zephyrinstead ofzephyras the path forzephyrprojectdirectoryvalue cannot escape the workspace, e.g.directory: ../..is an errordirectoryvalue is cumulative, e.g. if the imported manifest in turn does an import withdirectory: foo, then the combineddirectoryiszephyr_projects/fooAlternate suggested spellings for
directory:pathpath-prefixThe text was updated successfully, but these errors were encountered: