west init fails if ZEPHYR_BASE is set

[mlennig]

• https://github.com/zephyrproject-rtos/west/issues/212

Still an issue my dudes

[mlennig]

Miriams-Air-622:ncs miriamlennig$ west init -m https://github.com/NordicPlayground/fw-nrfconnect-nrf
West already initialized. Aborting.

[mbolivar]

Sorry for the long wait to reply.

TL;DR: this is intentional. If you have ZEPHYR_BASE set, it is used to find where the installation is located, which causes west init to believe you are already in one.

I don't like this at all but it was thrown in to support setups where people have ~/app and ~/zephyrproject/.west (etc.), i.e. applications entirely out of the west installation. In this case, running west build from ~/app breaks unless there's some other way to tell west where zephyr is. We argued about how to handle this (I suggested adding a new WEST_DIR variable to tell west where to look), but another suggestion to use ZEPHYR_BASE won the day.

I was hesitant about this at the time and still think it's not great, since it ties west's multirepo core to Zephyr in an abstraction-breaking way. But history's inertia won as it usually does.

I'm trying to get to a future where, if you're using west, zephyr-env.sh is never needed, and setting ZEPHYR_BASE in the parent environment will only be something to do if you're not using west (or if you're doing something

[Chandranshu9]

How can I resolve this issue?

[mbolivar-nordic]

Unset ZEPHYR_BASE.

[trond-snekvik]

Sorry to revive this old issue, but is there any way west init could just ignore this variable? There's no scenario where ZEPHYR_BASE is actually useful with west init, so west init just never works if you have set ZEPHYR_BASE. I can agree with the sentiment that ZEPHYR_BASE isn't the "right" way, to configure west, but it is documented as a valid workflow, so it's a bit unfortunate that it's incompatible with the most fundamental west command.

[marc-hb]

is there any way west init could just ignore this variable?

This would make west init different from other west commands. Granted it is already different by design but it would make west init even more different, especially in the implementation. https://cs.stanford.edu/people/eroberts/courses/cs181/projects/2010-11/WorseIsBetter/index.php/Worse-is-better.html

There's no scenario where ZEPHYR_BASE is actually useful with west init, so west init just never works if you have set ZEPHYR_BASE.

I don't think the second part is true. I wondered why #212 was marked as fixed and tested this. When there is no workspace where ZEPHYR_BASE points to (for instance when someone is deleting and "re-initing"), then west init works4me. It does seem to ignore a non-existing workspace at ZEPHYR_BASE.

So I think west init fails only when ZEPHYR_BASE points to a valid workspace somewhere else. Can you please elaborate on that use case, explain when it makes sense?

but it is documented as a valid workflow,

Barely?

• https://github.com/zephyrproject-rtos/zephyr/discussions/33521

[trond-snekvik]

When there is no workspace where ZEPHYR_BASE points (for instance when someone is deleting and "re-initing"), then west init works4me. It does seem to ignore a non-existing workspace at ZEPHYR_BASE.

I must admit I didn't think of this, but I don't think it's incompatible with a functional version of west init for ZEPHYR_BASE variables pointing at an initialized workspace though. IMO getting different behavior based on the state of another workspace than the one you're trying to create is a bit inconsistent from a user perspective.

Barely?

Freestanding applications are presented as a legitimate option in Zephyr's Application docs. Admittedly, the setup is not well documented, but there's nothing on that page that leads readers to believe that this isn't how west is supposed to be used. Arguably, it's even the most conventional way to pull in a software dependency of the three, so it's not that surprising if new users pick this before they get familiar enough with Zephyr and West to know that it can't be treated as an external library.

Can you please elaborate on that use cause, explain when it makes sense?

If you're working with a freestanding application, you've likely followed the Environment variables docs recommendation of setting ZEPHYR_BASE in .bashrc, or you invoke source zephyr-env.sh (either in .bashrc or at the start of each bash session).

Now, if you decide to convert to a workspace application, all the user guides (west init, "West basics", "Creating an application", "Moving to West") tell you to invoke west init -l <app>, which produces this error. As we want users to choose workspace applications over freestanding applications, we shouldn't make it harder than necessary to make the switch once the user is familiar enough with west to see the benefits. It's extra frustrating that everything the user had done to arrive at this error was either following convention or begin suggested by the documentation.

All in all, this is definitely more of a UX issue than a blocker for this use case, but it's right in the middle of a documented "happy path", and it doesn't appear to serve any purpose. A warning message in the relatively short output for this command seems more appropriate. Once the workspace is set up, ZEPHYR_BASE will be ignored anyway.

[marc-hb]

@mbolivar-ampere could you comment?

[mbolivar-ampere]

A warning message in the relatively short output for this command seems more appropriate.

I'm confused about what you're asking for, @trond-snekvik .

Do you want west init to ignore the variable, or do you want it to print a message?

Because it already prints a message:

% west init foo
FATAL ERROR: already initialized in /Users/mbolivar/zp, aborting.
Note:
    In your environment, ZEPHYR_BASE is set to:
    /Users/mbolivar/zp/zephyr

    This forces west to search for a workspace there.
    Try unsetting ZEPHYR_BASE and re-running this command.

Making west init ignore ZEPHYR_BASE entirely would introduce an inconsistency with how the workspace is discovered that would expose a few edge cases when running west init:

1. ZEPHYR_BASE is set and I am in the workspace it points inside
2. ZEPHYR_BASE is set and I am not in the workspace it points inside
3. ZEPHYR_BASE is unset and I am inside a workspace
4. ZEPHYR_BASE is unset and I am not inside a workpace

Right now, the cases always follow the rule "if you've told west what workspace to operate on, you can't run west init". Now it seems like you're asking for a more complicated rule.