support 'west init --topdir' #854

thorsten-klein · 2025-10-05T11:59:05Z

Fixes #774 (Successor of #775)

This PR introduces a new --topdir option for west init, allowing users to explicitly specify the west workspace directory (topdir) during initialization.

This is particularly useful when using --local, as the current behavior always sets the parent of the given directory as the topdir. In addition, west is currently unable to determine both manifest.path and manifest.file from a single directory argument as the path can be interpreted in multiple ways (e.g. it can be split at various places).

With the new --topdir argument, users can now directly control where the west workspace is created.

Parameterized tests for west init --topdir are added as well.

Moreover, the help texts and descriptions are (hopefully) simplified.

codecov · 2025-10-05T12:11:14Z

Codecov Report

❌ Patch coverage is 93.33333% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.03%. Comparing base (11302e1) to head (bb01594).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/west/app/project.py	93.33%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #854      +/-   ##
==========================================
+ Coverage   85.95%   86.03%   +0.08%     
==========================================
  Files          11       11              
  Lines        3453     3474      +21     
==========================================
+ Hits         2968     2989      +21     
  Misses        485      485

Files with missing lines	Coverage Δ
src/west/app/project.py	`80.91% <93.33%> (+0.39%)`	⬆️

mbolivar

Seems reasonable to me

pdgendt

Looks good!

pdgendt · 2025-10-08T15:57:05Z

@marc-hb I'm not sure if @fouge is very active? I think we can move forward with this?

src/west/app/project.py

marc-hb · 2025-10-14T03:04:12Z

I really want to review this one because I already spent a lot of time on #774 and #775 before but @thorsten-klein is just submitting way too much code, I can't keep up!

west did not use to be like this, help! :-D

Can you give me a few more days?

thorsten-klein · 2025-10-14T07:33:38Z

@thorsten-klein is just submitting way too much code, I can't keep up.

Sorry 🤞

Can you give me a few more days?

Yes, sure 👍🏻 Thank you in advance for your time and input!

carlescufi · 2025-10-15T08:09:53Z

@thorsten-klein is just submitting way too much code, I can't keep up.

Seconded, and I'll take this opportunity to thank you for all your contributions @thorsten-klein.

carlescufi

Even though I'd prefer --topdir was only compatible with -l, this is not a blocking issue for me. Thanks!

pdgendt · 2025-10-15T08:14:53Z

Let's wait for feedback from @marc-hb, as he requested some more time.

marc-hb

This is particularly useful when using --local

I downloaded this PR and tested the other, --manifest-url option and it does not seem to work for me. I ran out of time and did not try --local yet. I didn't look at the code either.

Describing directory nesting clearly and accurately is not easy - it is basically a "specification" except it has to be user-friendly too. So I will look at the code only when that "specification" is complete and unambiguous.

This help looks like the two last ones can be both used at the same time:

west init [-m URL] [--mr REVISION] [--mf FILE] [-o=GIT_CLONE_OPTION] [-t WORKSPACE_DIR] [directory]

But it's not actually possible:

FATAL ERROR: --topdir cannot be combined with positional argument [directory]

When using either separately, each one seems to have the same effect. So, there does not seem to be any new feature in the remote case, which means it's still not possible to west init a manifest two levels down or more in the remote case? Is this an oversight? The help does not seem to say. I don't see why --local would be more flexible than --manifest-url. I would hope the --manifest-url and --local options work the same immediately after the git clone operation.

src/west/app/project.py

marc-hb · 2025-10-16T02:48:29Z

This is particularly useful when using --local

I downloaded this PR and tested the other, --manifest-url option and it does not seem to work for me. I ran out of time and did not try --local yet. I didn't look at the code either.

Describing directory nesting clearly and accurately is not easy - it is basically a "specification" except it has to be user-friendly too. So I will look at the code only when that "specification" is complete and unambiguous (EDIT and of course: working for me).

This help looks like the two last ones can be both used at the same time:
west init [-m URL] [--mr REVISION] [--mf FILE] [-o=GIT_CLONE_OPTION] [-t WORKSPACE_DIR] [directory]
But it's not actually possible:
FATAL ERROR: --topdir cannot be combined with positional argument [directory]
When using either separately, each one seems to have the same effect. So, there does not seem to be any new feature in the remote case, which means it's still not possible to west init a manifest two levels down or more in the remote case? Is this an oversight? The help does not seem to say. I don't see why --local would be more flexible than --manifest-url. I would hope the --manifest-url and --local options work the same immediately after the git clone operation.

thorsten-klein · 2025-10-16T07:09:25Z

Thank you for the review 🙏

When using either separately, each one seems to have the same effect. So, there does not seem to be any new feature in the remote case, which means it's still not possible to west init a manifest two levels down or more in the remote case? Is this an oversight? The help does not seem to say. I don't see why --local would be more flexible than --manifest-url. I would hope the --manifest-url and --local options work the same immediately after the git clone operation.

Yes, exactly. --topdir and positional argument directory do exactly the same in remote case.
I have proposed to get rid of this positional argument at all, but it will not be accepted for now because it is a breaking change (what I fully understand).

Nevertheless, in remote case those arguments that do the same are mutually exclusive (see error message you got).
I have applied your suggested change, which totally make sense to point out in the help that they both cannot be combined ([--topdir DIR | directory]) 👍🏻

it's still not possible to west init a manifest two levels down or more in the remote case?

This has already worked before in remote case, since the positional argument [directory] already exists and it does exactly the same as --topdir (see above). The main value in this change lays in the local case (and is the pre-work to potentially remove the positional argument [directory] in future)

Thank you 👍🏻

thorsten-klein · 2025-10-16T13:16:39Z

I think I have resolved all review comments in the code👍🏻

marc-hb · 2025-10-17T00:59:07Z

it's still not possible to west init a manifest two levels down or more in the remote case?

This has already worked before in remote case, ...

Has it? Please share one example of a west init --manifest-url ... command that can produce this:

workspace
├── extra
│   └── level
│       └── manifest_clone
│           └── .git
└── .west

carlescufi · 2026-01-12T11:32:33Z

@marc-hb could you please follow-up on this PR?

outdated

marc-hb · 2026-01-13T04:25:10Z

Sorry I was on vacation and then it fell through the cracks. Will take another look ASAP

marc-hb

Partial review, I didn't get a chance to look at the test code yet, sorry. Later this week.

I’ve tried with the code to fail if the topdir is already initialized (when using --local). However, it seems that some tests (e.g. test_update_some_with_imports) rely on the current behavior and perform a re-initialization of some already initialized workspace.
What shall I do? It looks like this behavior might have been intentional, so I make it fail only when the new argument --topdir is used.

I'm amazed that such "reinit" situations exist, is it still the case? If yes, can you elaborate and provide a simple reproduction? This looks like a serious bug. Does it predate this PR? Does it simply deletes the existing .west/ directory? I can't believe there is code doing that.

You requested that west is able to create such a layout.

I only requested feature parity between --local and not --local. This is not "my" use case, this is the same use case than --local but when cloning.

Is this correct behavior or what would be your expectation when both args.topdir and directory are provided?
If they are mutually exclusive (as requested above), your requested feature will not be possible.

I don't remember requesting these they should be mutually exclusive, did I? I only remember experiencing that they were mutually exclusive in a previous version while the --help presented them as not mutually exclusive. So I requested to correct the help: #854 (comment)
Obviously, that's not relevant any more.

I find the current user interface confusing in the cloning case but:

it seems consistent with --local
it seems backwards-compatible
I can't think of a better one at this point.

marc-hb · 2026-01-14T03:21:36Z

src/west/app/project.py

+`.west/config`.
+The West manifest can come from either a remote repository (that will be cloned
+during workspace initialization) or from an already existing local directory.
+Config option `manifest.path` is set accordingly (see below).


This is too early for that implementation detail, you can drop that line here.

To be honest I'm not sure this name and implementation detail should be mentioned at all in the help text. But for sure not that early.

To me it was a helpful detail since I can directly see as a user what's the impact of this command.
Especially it helped to point out the difference between local and remote.

But I will remove 👍

marc-hb · 2026-01-14T03:28:27Z

src/west/app/project.py

        parser = self._parser(
            parser_adder,
            usage='''
+  init around a remote repository:


Suggested change

init around a remote repository:

init after cloning a manifest repository:

"around" something that does not exist yet sounds weird. "remote" sounds like it has to go over the network. I don't think it has.

I think it was some naming I have read anywhere and took over.
I would prefer having some shrt preposition.
Maybe one of those?

init workspace FROM an existing local manifest

init workspace WITH an existing local manifest

init workspace FOR an existing local manifest

I prefer WITH.

marc-hb · 2026-01-14T03:36:26Z

src/west/app/project.py

            '--manifest-url',
-            help='''manifest repository URL to clone;
+            metavar='URL',
+            help='''remote manifest repository URL to clone;


"remote" sounds like this must go over the network. I don't think it has to. I don't think this line needs to change. It already says "clone" so it's not ambiguous.

marc-hb · 2026-01-14T03:40:06Z

src/west/app/project.py

-                    in this case, and manifest.path points at
-                    "directory"''',
+            help='''initialize workspace around an already existing local
+                    manifest instead of cloning a remote manifest;


Suggested change

manifest instead of cloning a remote manifest;

manifest instead of cloning a manifest;

marc-hb · 2026-01-14T03:42:34Z

src/west/app/project.py

+            metavar='FILE',
+            help=f'''manifest file to use. It is the relative
+                     path of the manifest file within the remote repository
+                     respectively the local manifest_directory.


I don't think both cases need to be listed, it's the same thing in both cases. This just the "relative path TO the manifest file within the manifest directory" and that's IMHO enough. It does not matter whether that manifest directory is remote, local, or being cloned from a local disk. All that dilutes the information.

marc-hb · 2026-01-14T04:14:37Z

src/west/app/project.py

+If no `-m / --manifest-url` is provided, west uses Zephyr URL by default:
+  {MANIFEST_URL_DEFAULT}.
+
+The topdir (where `.west` is created) is determined as follows:


(It really sucks we have to keep such a complicated logic for backwards compatibility)

To simplify the logic, we can just deprecate using a positional argument instead of the new --topdir. This will make the local and cloning case more consistent with each other.

I would propose to add the --topdir feature here, and do this deprecation in a separate PR.

Agreed for a separate PR, glad you're ok with the deprecation idea. Can you please add a comment in the code now? "# This case will be deprecated later". And in the corresponding test code if any.

marc-hb · 2026-01-14T04:15:22Z

src/west/app/project.py

+2. Local Manifest
+-----------------
+If `-l / --local` is given, west initializes a workspace around an already
+existing `west.yml`. Its location can be specified in `manifest_directory`


Suggested change

existing `west.yml`. Its location can be specified in `manifest_directory`

existing `west.yml`. Its location can be specified in the `manifest_directory` positional argument

marc-hb · 2026-01-14T04:16:45Z

src/west/app/project.py

+-----------------
+If `-l / --local` is given, west initializes a workspace around an already
+existing `west.yml`. Its location can be specified in `manifest_directory`
+(defaults to current working directory). Config option `manifest.path` is set


Suggested change

(defaults to current working directory). Config option `manifest.path` is set

It defaults to current working directory.

No parenthesis.

Is mentioning manifest.path really required at all in this help text? I think the west documentation should be enough.

marc-hb · 2026-01-14T04:19:46Z

src/west/app/project.py

            # is PurePosixPath.
            manifest_path = PurePath(urlparse(manifest_url).path).name

+        manifest_path = str(Path(subdir) / manifest_path)


Why does need to be converted to a string? The comment just above warns about this needing to be a PurePath in some cases...

For setting the option the value have to be str: TypeError: option values must be strings
I have moved to conversion to the function call now 👍

marc-hb · 2026-01-14T04:25:47Z

src/west/app/project.py

+        if args.topdir:
+            topdir = Path(args.topdir).resolve()
+            try:
+                already = util.west_topdir(topdir, fall_back=False)


Suggested change

already = util.west_topdir(topdir, fall_back=False)

already = util.west_topdir(manifest_dir, fall_back=False)

We want to maximize the chances of finding an existing workspace, not minimize them.

Also: move the manifest_file.is_relative_to(topdir): check first.

I think this is not correct.
E.g. --topdir workspace --local /path/to/my/manifest should only fail if topdir is already a workspace, not if any parent of the manifest is already a workspace.

Ok.

need to review updated version

marc-hb

manifest_path: Path = Path(subdir) / mf_path

This line does not make sense to me, see below.

marc-hb · 2026-01-17T00:15:29Z

src/west/app/project.py

+--mf
+    The relative path to the manifest file within the manifest repository
+    (remote or local). Config option manifest.file will be set to this value.
+    Defaults to `{_WEST_YML}` if not provided.


Backquotes are useful in .rst docs but they look weird. Not important.

marc-hb · 2026-01-17T00:24:39Z

src/west/app/project.py

+
+If both `-t / --topdir` and `directory` are provided, `-t / --topdir`
+specifies the workspace directory, while `directory` specifies the subfolder
+within the workspace where the repository is cloned during initialization


Suggested change

within the workspace where the repository is cloned during initialization

within the workspace where the manifest repository is cloned during initialization

marc-hb · 2026-01-17T00:25:04Z

src/west/app/project.py

+
+The topdir (where `.west` is created) is determined as follows:
+- argument `-t / --topdir` if provided
+- otherwise: argument `directory` if provided


Suggested change

- otherwise: argument `directory` if provided

- otherwise: the positional `directory` argument if provided without --topdir. Deprecated: prefer --topdir.

I think if provided without --topdir is not relevant (same as your comment above where I removed if -m is used).
Also here I would propose to do the Deprecation in a separate PR.

marc-hb · 2026-01-17T00:26:35Z

src/west/app/project.py

+- otherwise: the current working directory
+
+If both `-t / --topdir` and `directory` are provided, `-t / --topdir`
+specifies the workspace directory, while `directory` specifies the subfolder


Suggested change

specifies the workspace directory, while `directory` specifies the subfolder

specifies the workspace directory, while the positional directory argument specifies the manifest subfolder

marc-hb · 2026-01-17T00:29:33Z

src/west/app/project.py

+If no `-m / --manifest-url` is provided, west uses Zephyr URL by default:
+  {MANIFEST_URL_DEFAULT}.
+
+The topdir (where `.west` is created) is determined as follows:


To simplify the logic, we can just deprecate using a positional argument instead of the new --topdir. This will make the local and cloning case more consistent with each other.

marc-hb · 2026-01-17T00:33:28Z

src/west/app/project.py

+            metavar='directory',
+            help='''With --local: the path to a local directory which contains
+                    a west manifest (west.yml);
+                    Otherwise (if -m is used and no --topdir is provided):


Wait: -m is not relevant here, is it?

Suggested change

Otherwise (if -m is used and no --topdir is provided):

Otherwise, if no --topdir is provided:

marc-hb · 2026-01-17T01:00:14Z

src/west/app/project.py

+        topdir = Path(args.topdir or manifest_dir.parent).resolve()
+
+        if not manifest_file.is_relative_to(topdir):
+            self.die(f'{manifest_file} must be relative to west topdir')


Suggested change

self.die(f'{manifest_file} must be relative to west topdir')

self.die(f'{manifest_file} must be relative to west topdir {topdir}')

marc-hb · 2026-01-17T01:10:44Z

src/west/app/project.py

+                    )
+                subdir = os.path.relpath(args.directory, topdir)
+        elif args.directory:
+            topdir = Path(abspath(args.directory))


Suggested change

topdir = Path(abspath(args.directory))

self.wrn(f"DEPRECATED, use --topdir {args.directory} instead")

topdir = Path(abspath(args.directory))

I would propose to do the deprecation in a separate PR.

marc-hb · 2026-01-17T02:00:54Z

src/west/app/project.py

+        if args.topdir:
+            topdir = Path(abspath(args.topdir))
+            if args.directory:
+                if not Path(abspath(args.directory)).is_relative_to(topdir):


abspath(args.directory) does not make sense because args.directory is meant to be appended to topdir first. And then the former is automatically relative to the latter. So this check does not make sense to me.

marc-hb · 2026-01-17T02:04:32Z

src/west/app/project.py

-            manifest_path = PurePath(urlparse(manifest_url).path).name
+            mf_path = PurePath(urlparse(manifest_url).path).name

+        manifest_path: Path = Path(subdir) / mf_path


This looks like a misunderstanding... manifest.path comes either from the command line, or from self.path in the manifest file, but it's never a combination of both. If both are defined, the code should fail if they don't match.

If none is defined, keeping falling back on basename(url) like before.

Without prepending subdir the test fails when topdir is Path('subdir') and the positional argument directory is Path('subdir') / 'extra' / 'level')

As per definition:

If both `-t / --topdir` and `directory` are provided, `-t / --topdir` specifies the workspace directory, while positional argument `directory` specifies the subfolder within the workspace where the manifest repository is cloned during initialization

Therefore the manifest will be located under <topdir>/<subdir>/<yml_path>

UPDATE: I have locally merged your PR (#906) and all tests still pass 👍🏻

Without prepending subdir the test fails...

Tests are only a means to an end, if they don't reflect the desired behavior then they need to change.

As per definition

In the --local case, the positional argument becomes manifest.path[*]. For consistency, I think we want the same in the cloning case. If that clashes with self.path then we should either error or warn, not sure which.

[*] Not "literally" because absolute/relative but they do point at the same directory.

I’m not sure we’re talking about the same thing. Let’s align.

When west init --topdir subdir subdir/extra/level is invoked, my expectation is that:

The workspace is created under ./subdir, i.e. ./subdir/.west is created.

The Zephyr repository is cloned to <topdir>/extra/level/zephyr/.git (which is ./subdir/extra/level/zephyr/.git).

The manifest.path config option points to extra/level/zephyr.

The manifest.file config option is set to west.yml.

Does this match your expectations? Am I incorrect about any of these points, or missing something important?

The Zephyr repository is cloned to /extra/level/zephyr/.git

No this does not match my expectations. For consistency with west init -l topdir/extra/level/zephyr, I'm expecting west init --topdir topdir topdir/extra/level/zephyr + an error or a warning when self.path is present and different from extra/level/zephyr. Long story short, all these arguments should always point at the manifest directory for consistency. Some arguments may be absolute, others like self.path must be relative but they should all point to the same directory in the end for simplicity. In case of a failure becaus of a conflict with self.path, the error message could require the users to 1. clone 2. west init in two steps.

Please prove me wrong and demonstrate that there is a more user-friendly UI design, but again it would have been more efficient to have this very discussion about the user interface and design first in #774 BEFORE writing the corresponding code, rather then "reserve-engineering" the code at code review time to discover that the UI design was not formalized.

This PR is 100% about nesting subdirectories, an area where "off by one" and similar errors are extremely common[*]. So it is critical to pay great attention to such nesting details. This is also why I repeatedly warned about phrasing like "thing gets created inside dir0" in the help text: does it mean "thing=dir0" or "dir0/thing"? No one knows. Less ambiguous language is required.

[*] examples:

https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb

https://unix.stackexchange.com/questions/402555/why-add-a-trailing-slash-after-an-rsync-destination

Run cp -r dir0/ dir1/ twice, starting with non-existent dir1. Results depend on the operating system!

Let's try to figure out the actual disagreement here, step by step. First of all, let's use proper full commands. @marc-hb and @thorsten-klein in the examples you are providing above with west init —topdir you are not including -l nor -m. Can we start by defining the full command-line arguments of the command that you @marc-hb think should work differently?

tests/test_project.py

src/west/app/project.py

Added new argument for west init to specify the west topdir when a workspace is inizialized.

marc-hb · 2026-01-19T21:20:42Z

From #854 (comment)

but again it would have been more efficient to have this very discussion about the user interface and design first BEFORE writing the corresponding code, rather then "reserve-engineering" the code at code review time to discover that the UI design was not formalized.

Also, it's very time-consuming and error prone to have high-level design discussions buried in in tens of comments about typos and other, low-level implementation details. Let's discuss user interface and other high-level design points in issue #774 rather than in this PR. #774 is a bit noisy because of some initial misunderstandings but it's not as noisy as here.

multiple combinations of arguments are tested as they can be provided to 'west init'.

carlescufi · 2026-01-22T11:19:39Z

From #854 (comment)

but again it would have been more efficient to have this very discussion about the user interface and design first BEFORE writing the corresponding code, rather then "reserve-engineering" the code at code review time to discover that the UI design was not formalized.

Also, it's very time-consuming and error prone to have high-level design discussions buried in in tens of comments about typos and other, low-level implementation details. Let's discuss user interface and other high-level design points in issue #774 rather than in this PR. #774 is a bit noisy because of some initial misunderstandings but it's not as noisy as here.

In an ideal world, sure. But I think in this particular case we are already too far ahead in the implementation and design to change the location of the discussions in my opinion. Reading your comments, I don't think we are that far from agreeing to a solution here, so @thorsten-klein perhaps we can try to resolve the last points (specifically this comment).

marc-hb · 2026-01-22T19:24:59Z

But I think in this particular case we are already too far ahead in the implementation and design to change the location of the discussions in my opinion

It's not really a "change" because all the --topdir user interface and high-level design discussion happened in #774 in the first place and the majority of it is still there. Even after this gets merged, someone wondering about the user interface would rather stick to #774 and not have to get lost in typos and other implementation details to find rationale(s).

BTW I'm writing "high-level design" as in "looking at the --help, not the code". This is only about defining what the command-line parameters mean, it's not advanced maths! It's just faster to discuss and define this before writing and reviewing the code, that's all.

I don't think we are that far from agreeing to a solution here

Agreed, and I also love being proven wrong. I'm only upset about the time-consuming way to get there.

EDIT, trying to be fair: @thorsten-klein did not initially intend to implement --topdir and cloning at the same time and graciously accepted to add that during the review. But that entire discussion should still have happened before writing any code.

thorsten-klein mentioned this pull request Oct 5, 2025

west init gives wrong config path for a manifest file in nested directories #774

Open

mbolivar reviewed Oct 5, 2025

View reviewed changes

pdgendt approved these changes Oct 6, 2025

View reviewed changes

pdgendt requested a review from marc-hb October 7, 2025 12:35

marc-hb mentioned this pull request Oct 7, 2025

app: more versatile initialization for path in config #775

Closed

thorsten-klein requested a review from mbolivar October 9, 2025 15:42

carlescufi reviewed Oct 10, 2025

View reviewed changes

src/west/app/project.py Outdated Show resolved Hide resolved

src/west/app/project.py Outdated Show resolved Hide resolved

src/west/app/project.py Outdated Show resolved Hide resolved

pdgendt requested changes Oct 10, 2025

View reviewed changes

src/west/app/project.py Outdated Show resolved Hide resolved

thorsten-klein force-pushed the west-init-topdir branch 3 times, most recently from 652408c to 8a2e15e Compare October 10, 2025 20:37

thorsten-klein requested review from carlescufi and pdgendt October 10, 2025 20:37

pdgendt previously approved these changes Oct 13, 2025

View reviewed changes

thorsten-klein force-pushed the west-init-topdir branch 2 times, most recently from a08dec0 to 99377aa Compare October 15, 2025 06:08

carlescufi approved these changes Oct 15, 2025

View reviewed changes

marc-hb requested changes Oct 16, 2025

View reviewed changes

thorsten-klein force-pushed the west-init-topdir branch from 99377aa to 552f964 Compare October 16, 2025 07:16

thorsten-klein requested a review from marc-hb October 16, 2025 07:43

thorsten-klein force-pushed the west-init-topdir branch 2 times, most recently from dd0e9e3 to 8e07584 Compare October 28, 2025 16:53

thorsten-klein marked this pull request as draft November 6, 2025 08:42

thorsten-klein force-pushed the west-init-topdir branch from 8e07584 to 0c4ecf8 Compare December 18, 2025 16:10

thorsten-klein requested review from marc-hb and pdgendt December 18, 2025 16:29

thorsten-klein marked this pull request as ready for review December 18, 2025 16:30

marc-hb reviewed Jan 14, 2026

View reviewed changes

thorsten-klein force-pushed the west-init-topdir branch from 0c4ecf8 to c3674bf Compare January 15, 2026 12:48

thorsten-klein force-pushed the west-init-topdir branch from c3674bf to 5d88b67 Compare January 15, 2026 13:04

marc-hb requested changes Jan 17, 2026

View reviewed changes

marc-hb mentioned this pull request Jan 17, 2026

project: die if the --manifest-file argument is not relative #906

Merged

thorsten-klein force-pushed the west-init-topdir branch from 5d88b67 to 9647d77 Compare January 17, 2026 10:03

pdgendt reviewed Jan 19, 2026

View reviewed changes

tests/test_project.py Show resolved Hide resolved

thorsten-klein force-pushed the west-init-topdir branch from 9647d77 to 88035ae Compare January 19, 2026 09:28

pdgendt reviewed Jan 19, 2026

View reviewed changes

tests/test_project.py Outdated Show resolved Hide resolved

thorsten-klein force-pushed the west-init-topdir branch from 88035ae to 553ce1a Compare January 19, 2026 09:51

pdgendt reviewed Jan 19, 2026

View reviewed changes

src/west/app/project.py Outdated Show resolved Hide resolved

src/west/app/project.py Outdated Show resolved Hide resolved

support 'west init --topdir'

691a5d1

Added new argument for west init to specify the west topdir when a workspace is inizialized.

thorsten-klein force-pushed the west-init-topdir branch from 553ce1a to 482e8d4 Compare January 19, 2026 12:18

add extensive tests for 'west init' and 'west init --topdir'

bb01594

multiple combinations of arguments are tested as they can be provided to 'west init'.

thorsten-klein force-pushed the west-init-topdir branch from 482e8d4 to bb01594 Compare January 20, 2026 15:40

pdgendt mentioned this pull request Jan 29, 2026

feat: add --topdir commandline option #913

Closed

	init around a remote repository:
	init after cloning a manifest repository:

	manifest instead of cloning a remote manifest;
	manifest instead of cloning a manifest;

	existing `west.yml`. Its location can be specified in `manifest_directory`
	existing `west.yml`. Its location can be specified in the `manifest_directory` positional argument

	(defaults to current working directory). Config option `manifest.path` is set
	It defaults to current working directory.

	already = util.west_topdir(topdir, fall_back=False)
	already = util.west_topdir(manifest_dir, fall_back=False)

	within the workspace where the repository is cloned during initialization
	within the workspace where the manifest repository is cloned during initialization

	- otherwise: argument `directory` if provided
	- otherwise: the positional `directory` argument if provided without --topdir. Deprecated: prefer --topdir.

	specifies the workspace directory, while `directory` specifies the subfolder
	specifies the workspace directory, while the positional directory argument specifies the manifest subfolder

	Otherwise (if -m is used and no --topdir is provided):
	Otherwise, if no --topdir is provided:

	self.die(f'{manifest_file} must be relative to west topdir')
	self.die(f'{manifest_file} must be relative to west topdir {topdir}')

	topdir = Path(abspath(args.directory))
	self.wrn(f"DEPRECATED, use --topdir {args.directory} instead")
	topdir = Path(abspath(args.directory))

support 'west init --topdir' #854

Are you sure you want to change the base?

support 'west init --topdir' #854

Uh oh!

Conversation

thorsten-klein commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

mbolivar left a comment

Choose a reason for hiding this comment

Uh oh!

pdgendt left a comment

Choose a reason for hiding this comment

Uh oh!

pdgendt commented Oct 8, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marc-hb commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thorsten-klein commented Oct 14, 2025

Uh oh!

carlescufi commented Oct 15, 2025

Uh oh!

carlescufi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pdgendt commented Oct 15, 2025

Uh oh!

marc-hb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marc-hb commented Oct 16, 2025

Uh oh!

thorsten-klein commented Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thorsten-klein commented Oct 16, 2025

Uh oh!

marc-hb commented Oct 17, 2025

Uh oh!

carlescufi commented Jan 12, 2026

Uh oh!

marc-hb commented Jan 13, 2026

Uh oh!

marc-hb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

thorsten-klein commented Oct 5, 2025 •

edited

Loading

codecov bot commented Oct 5, 2025 •

edited

Loading

marc-hb commented Oct 14, 2025 •

edited

Loading

carlescufi left a comment •

edited

Loading

thorsten-klein commented Oct 16, 2025 •

edited

Loading

marc-hb Jan 17, 2026 •

edited

Loading

thorsten-klein Jan 15, 2026 •

edited

Loading

thorsten-klein Jan 17, 2026 •

edited

Loading