pyproject.toml introduction

[christag-ni]

What does this Pull Request accomplish?

Changes the toolchain version pulled in, so we're now using version gcc 7+. We would've pulled the toolchain directly from the nilrt repo, but other teams faced difficulty attempting that route.

Why should this Pull Request be merged?

Events are not able to run tests, presumably failing because gcc 6.3 isn't compatable with GLIBCXX_3.4.30

What testing has been done?

None

[bkeryan]

FYI, here's what your build failure is about:

Created package validate_examples in .
Creating virtualenv validate-examples-WQIUftue-py3.8 in /home/runner/.cache/pypoetry/virtualenvs
Using version ^1.70.0 for grpcio

Updating dependencies
Resolving dependencies...

Writing lock file

Package operations: 1 install, 0 updates, 0 removals

  • Installing grpcio (1.70.0)
The --dev option is deprecated, use the `--group dev` notation instead.

Poetry used to have special syntax for "dev-dependencies", but now it has more general "group" feature and "dev-dependencies" are now just a group named "dev".

Using version ^1.70.0 for grpcio-tools
Using version ^1.[15](https://github.com/ni/grpc-device/actions/runs/13440643623/job/37553976481?pr=1151#step:7:16).0 for mypy
Using version ^3.6.0 for mypy-protobuf
Using version ^5.29.1.[20](https://github.com/ni/grpc-device/actions/runs/13440643623/job/37553976481?pr=1151#step:7:21)250208 for types-protobuf
Using version ^1.53.0.5 for grpc-stubs

This project creates a Poetry project on the fly and uses poetry add to add dependencies. This is not how you normally use Poetry. Normal usage is to check the pyproject.toml and poetry.lock into version control.

I think it's using poetry add to add dependencies, and the default version constraint is basically ">= the current latest version, < the next major version".

Updating dependencies
Resolving dependencies...

The current project's Python requirement (>=3.8,<4.0) is not compatible with some of the required packages Python requirement:
  - types-protobuf requires Python >=3.9, so it will not be satisfied for Python >=3.8,<3.9

Because types-protobuf (5.29.1.20[25](https://github.com/ni/grpc-device/actions/runs/13440643623/job/37553976481?pr=1151#step:7:26)0208) requires Python >=3.9
 and no versions of types-protobuf match >5.29.1.20250208,<6.0.0.0, types-protobuf is forbidden.
So, because validate-examples depends on types-protobuf (^5.[29](https://github.com/ni/grpc-device/actions/runs/13440643623/job/37553976481?pr=1151#step:7:30).1.20250208), version solving failed.

  • Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties
    
    For types-protobuf, a possible solution would be to set the `python` property to ">=3.9,<4.0"

    https://python-poetry.org/docs/dependency-specification/#python-restricted-dependencies,
    https://python-poetry.org/docs/dependency-specification/#using-environment-markers
The --dev option is deprecated, use the `--group dev` notation instead.

The latest protobuf no longer supports Python 3.8, so the latest types-protobuf no longer supports Python 3.8. However, because the PR workflow used poetry add, the version constraint in pyproject.toml requires the latest types-protobuf.

If the pyproject.toml was checked into version control, it could continue using older versions of protobuf and types-protobuf, and the existence of a newer version would not break the grpc-device PR build.

Also, if the pyproject.toml and poetry.lock were checked into version control, this repo could use Renovate Bot to automatically create PRs when new dependency versions are released, which would catch issues like this sooner instead of breaking an unrelated PR's build.

Cc: @mshafer-NI @maxxboehme @astarche @reckenro

[bkeryan]

The Python example validation looks good.

[christag-ni]

As per @bkeryan's request, this PR will only focus on Python fixes. The Linux toolchain fixes will be in a separate PR.

[christag-ni]

@bkeryan I'm a bit confused: did you want my pyproject.toml changes to go in before upgrading the linux toolchain version? I assumed this PR would pull in Gabe's changes from grpc-sideband and fix the failing check.

[bkeryan]

@bkeryan I'm a bit confused: did you want my pyproject.toml changes to go in before upgrading the linux toolchain version? I assumed this PR would pull in Gabe's changes from grpc-sideband and fix the failing check.

I asked "Is it possible to check in the Python fixes separately from the Linux toolchain update?"

If you can't complete the PR because the Linux build is still broken, then I suppose the answer is "no".

[christag-ni]

@bkeryan I'm a bit confused: did you want my pyproject.toml changes to go in before upgrading the linux toolchain version? I assumed this PR would pull in Gabe's changes from grpc-sideband and fix the failing check.

I asked "Is it possible to check in the Python fixes separately from the Linux toolchain update?"

If you can't complete the PR because the Linux build is still broken, then I suppose the answer is "no".

Oh...in that case, no I can't. I assume the only way around this is to combine all changes into one PR?

[bkeryan]

Oh...in that case, no I can't. I assume the only way around this is to combine all changes into one PR?

I think #1155 may fix your current build failure.