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

Modernize python build setup, protoc dependency #783

Merged
merged 4 commits into from
Mar 25, 2024
Merged

Conversation

pmai
Copy link
Contributor

@pmai pmai commented Feb 28, 2024

This moves most meta-data to pyproject.toml, automates the version handling and makes it available at runtime, depends on protoc via the protoc-wheel-0 package, makes sdist and bdist distributions work correctly, and removes dependencies that are not build dependencies, but rather used only in CI.

@pmai pmai force-pushed the build/modernize-python branch 7 times, most recently from 2923784 to 6968c07 Compare February 29, 2024 11:37
@jdsika jdsika added the Quality Quality improvements. label Mar 6, 2024
{name = "ASAM Open Simulation Interface Project", email = "[email protected]"},
]
dependencies = [
"protobuf>=4.24.4",
Copy link
Contributor

Choose a reason for hiding this comment

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

better == ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Conservatively == would likely be better, however there might be some leeway here, which is why I have for now left it at >=, but might change to == prior to finalizing the PR.

requires = [
"setuptools",
"wheel",
"protoc-wheel-0==24.4",
Copy link
Contributor

Choose a reason for hiding this comment

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

In the protobuf.yml, the protobuf version in configurable as an environment variable. Currently it is set to 3.20.1:

PROTOBUF_VERSION: 3.20.1

How does this fit to the hardcoded protobuf version here, and also in the dependencies below?
In my PR regarding this topic I tried to make the python protobuf version coherent with the installed protoc version on the system.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The protobuf.yml is just our test build pipeline, i.e. how we test any changes, especially also the C++ side.
This does not hard-code any actual requirements, it just controls our build environment so that our build environment stays half-way stable.

The pyproject.toml will define how others build the python packages. Since this requires easy access to a suitable protoc (and a matching runtime), we build-depend the python package on a fixed version of protoc-wheel-0, which we then also have to use as a dependency for the protobuf runtime. Since none of this works very well with dynamic dependencies, this more or less has to be hard-coded. In the end we might converge on one version between CI and python package, but that is really independent.

This PR prepares the complete separation of the C++ and python build processes, which should have happened in the first place, and also - in a later PR - separates our CI from the package requirements.

We really, really do not want to have hard version requirements across projects, so osi-validator can just depend on the osi3 python package with a >= requirement, and not have any dependencies on protobuf at all.

Copy link
Contributor

Choose a reason for hiding this comment

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

The protobuf.yml is just our test build pipeline.

Yes, but we now test the C++ build with 3.20.1 and the Python build with 24.4.

Just for my understanding: To build OSI for C++, I need to have the protoc compiler installed on my system, with any protobuf version. The python build is independent of that protoc compiler and it always uses version 24.4 (unless of course I change the toml file). Is that correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The protobuf.yml is just our test build pipeline.

Yes, but we now test the C++ build with 3.20.1 and the Python build with 24.4.

Yes, and we might or might not switch to something newer on the C++ side, however that is now independent of the Python side (since for Python it means what we ship, not what we test, whereas for C++ it only means what we test). In any case the C++ changes would be handled in a separate PR.

Just for my understanding: To build OSI for C++, I need to have the protoc compiler installed on my system, with any protobuf version. The python build is independent of that protoc compiler and it always uses version 24.4 (unless of course I change the toml file). Is that correct?

Yes, though the python build scripts have a way of falling back to system- or user-supplied protoc, if you want that. Just by default they will build-depend on the protoc-wheel-0 package and use that for building.

@ClemensLinnhoff
Copy link
Contributor

Unit tests need to be fixed. There seem to be some issues due to the renaming of the format folder, see pipeline run.

@jdsika
Copy link
Contributor

jdsika commented Mar 6, 2024

Proto 3.6.1 in use for OSI-Validation at BMW

@thomassedlmayer
Copy link
Contributor

@pmai In formatting_scripts.adoc there is a note that converted.txth is the default name of the output file. This should be changed as now the default name is the input file name.

@jdsika
Copy link
Contributor

jdsika commented Mar 22, 2024

@pmai will this be ready to merge next CCB?

@pmai pmai added the ReadyForCCBReview Indicates that this MR is ready for a final review and merge by the CCB. label Mar 22, 2024
@pmai pmai self-assigned this Mar 22, 2024
@pmai
Copy link
Contributor Author

pmai commented Mar 22, 2024

@pmai In formatting_scripts.adoc there is a note that converted.txth is the default name of the output file. This should be changed as now the default name is the input file name.

Yes, that was however already wrong prior to this PR, so I would suggest fixing in separate PR.

@pmai
Copy link
Contributor Author

pmai commented Mar 25, 2024

CCB 2025-03-25: Merge as-is.

@pmai pmai added ReadyToMerge This PR has been approved to merge and will be merged by a member of the CCB. and removed ReadyForCCBReview Indicates that this MR is ready for a final review and merge by the CCB. labels Mar 25, 2024
This moves most meta-data to pyproject.toml, automates the version
handling and makes it available at runtime, depends on protoc via
the protoc-wheel-0 package, makes sdist and bdist distributions
work correctly, and removes dependencies that are not build
dependencies, but rather used only in CI.

Signed-off-by: Pierre R. Mai <[email protected]>
Also renames the module file to fit PEP-8 conventions.

Signed-off-by: Pierre R. Mai <[email protected]>
@pmai pmai merged commit 118d13c into master Mar 25, 2024
8 checks passed
@pmai pmai deleted the build/modernize-python branch March 25, 2024 11:35
@pmai pmai added this to the V3.7.0 milestone Apr 4, 2024
@jdsika
Copy link
Contributor

jdsika commented Apr 24, 2024

I was a bit confused about the diff at first but this was a mix of moving files and linter. so OK

Reviewed for v3.7.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Quality Quality improvements. ReadyToMerge This PR has been approved to merge and will be merged by a member of the CCB.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants