Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

venv: Add support for virtual environment specs #736

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

yperess
Copy link

@yperess yperess commented Sep 13, 2024

Adds handling for a venv key in the manifest. This key will then be used to provide virtual environment metadata to a west bootstrap command. The metadata includes:

  • A virtual environment name
  • A list of python requirement files, individual packages, constraints, and local directories.
  • A mapping of binary requirements and which URLs can be used to find them. These include architecture and OS specific mappings.

@yperess yperess force-pushed the main branch 2 times, most recently from 5b0793c to b6d9ffb Compare September 13, 2024 15:42
@yperess
Copy link
Author

yperess commented Sep 16, 2024

@nashif what's the process for getting this PR reviewed?

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is IMHO missing some high-level descriptions of the problem statement and of the solution's design. I'm especially wondering what a "binary requirement" is?

I think the best way to fix that would be a corresponding documentation PR, for instance see how this unrelated feature had a separate documentation PR:
zephyrproject-rtos/zephyr#76027

west documentation is unfortunately located in the Zephyr repo for various reasons: fewer sites to maintain, single place for west built-ins and Zephyr extensions,...

The obvious drawback is: PRs like these must be split across two repos.

PS: there is a shortage of west maintainers right now.

elif current_os == "Linux":
defs["os"] = "linux"
else:
raise RuntimeError("Unknown OS: " + current_os)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this code run when you don't use the new feature?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It did, thanks for catching it. I've moved it to a lazily initialized class so it only gets run if you're using the feature.

if current_os == "Windows":
defs["os"] = "windows"
elif current_os == "Darwin":
defs["os"] = "mac"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this indirection really necessary?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added more details above in the architecture remapping. Chromium provides a free package database which is very very robust. These OS names are what's used in CIPD so having these as the "standard" gives us access to the whole database without any complexity to the manifest.

@@ -67,6 +68,64 @@
# Internal helpers
#

# Mapping of the architectures from platofrm.machine() to a common standard
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean, to some "Zephyr" standard? I agree "Darwin" is a little bit cryptic but aaarch64 is not.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK, I updated the comment to specify where the "standard" came from. I don't think it matters a ton, but I do think that it's a good standard to follow since it makes the URL constructions compatible with a very large database.

@@ -66,6 +66,78 @@ mapping:
required: true
type: str

# The venv key specifies requirements for the build environment for Zephyr
Copy link
Collaborator

@marc-hb marc-hb Sep 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code in this repo is supposed to be not specific to Zephyr. Is this PR Zephyr-specific? I don't have time for a full review sorry.

If it is Zephyr-specific, then it belongs to https://github.com/zephyrproject-rtos/zephyr/tree/main/scripts/west_commands

Considering west build is Zephyr-specific, I suspect this PR is too.

Even if it's not Zephyr-specific, https://github.com/zephyrproject-rtos/zephyr/tree/main/scripts/west_commands could be a good "staging" area to gather feedback, real-use and... more reviewers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not Zephyr specific but will be used in a Zephyr west command. The goal of this change is to add metadata about a project's requirements (both python and binary).

@yperess
Copy link
Author

yperess commented Sep 18, 2024

This is IMHO missing some high-level descriptions of the problem statement and of the solution's design. I'm especially wondering what a "binary requirement" is?

I think the best way to fix that would be a corresponding documentation PR, for instance see how this unrelated feature had a separate documentation PR: zephyrproject-rtos/zephyr#76027

west documentation is unfortunately located in the Zephyr repo for various reasons: fewer sites to maintain, single place for west built-ins and Zephyr extensions,...

The obvious drawback is: PRs like these must be split across two repos.

PS: there is a shortage of west maintainers right now.

Thank you for the review. I've added a WIP CL that uses this and adds documentation at zephyrproject-rtos/zephyr#78610. It's a WIP because I haven't had the chance to track down all the binary dependencies though I got a few of them (enough to see how this PR will be used).

@yperess yperess force-pushed the main branch 2 times, most recently from 8faab3a to 91d41dd Compare September 18, 2024 07:05
Adds handling for a venv key in the manifest. This key will then be
used to provide virtual environment metadata to a west bootstrap command.
The metadata includes:
- A virtual environment name
- A list of python requirement files, individual packages, constraints,
  and local directories.
- A mapping of binary requirements and which URLs can be used to find
  them. These include architecture and OS specific mappings.

Signed-off-by: Yuval Peress <[email protected]>
Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a big no-go from my side.

The west manifest should not start to contain a bunch of keys and values not relevant or used by core west itself.

Nor should it contain a bunch of information which may not be of interest to several users of the manifest.

See also this comment for more details: zephyrproject-rtos/zephyr#78610 (review)

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 18, 2024

Thanks for submitting zephyrproject-rtos/zephyr#78610, I also replied there. Once the dust settles there we can revisit what belongs to Zephyr versus what belongs to west itself.

@marc-hb marc-hb marked this pull request as draft September 18, 2024 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants