opentelemetry-python
opentelemetry-python copied to clipboard
open-telemetry
Update package metadata
Background
Hello there! The Python packaging ecosystem has standardized on the interface for build backends (PEP 517/PEP 660) and the format for metadata declaration (PEP 621/PEP 631). As a result, the execution of setup.py files is now deprecated.
So, I'm spending my free time updating important projects so that they are modernized and set an example for others 😄
Description
This implements PEP 621 for opentelemetry-api, obviating the need for setup.py, setup.cfg, and MANIFEST.in. Our tooling already supports this. I'll open one PR per package after this one.
The build backend hatchling (of which I am a maintainer in the PyPA) is now used as that is the default in the official Python packaging tutorial. Hatchling is available on all the major distribution channels such as Debian, Fedora, Arch Linux, conda-forge, Nixpkgs, Alpine Linux, FreeBSD, Gentoo Linux, MacPorts, OpenEmbedded, Spack, etc.
The earliest supported Python 3 version of Hatchling is 3.7, therefore I've also set that as the minimum here in accordance with our support policy as Python 3.6 reached EOL more than 6 months ago.
Type of change
- [X] This change requires a documentation update
How Has This Been Tested?
tox -e py38-opentelemetry-api
Does This PR Require a Contrib Repo Change?
- [ ] Yes. - Link to PR:
- [X] No.
Checklist:
- [ ] Followed the style guidelines of this project
- [ ] Changelogs have been updated
- [ ] Unit tests have been added
- [X] Documentation has been updated
@ofek probably not since this doesn't change anything for an end user but we might want to discuss the dropping support for 3.6. We decided to keep it until around metrics SDK becomes stable enough.
No worries, in that case I can keep the existing cap and only require 3.7+ in CI/CD. How does that sound?
No worries, in that case I can keep the existing cap and only require 3.7+ in CI/CD. How does that sound?
sgtm
Everything is passing now! Though it looks like the 3.6 jobs are hard coded in this repo's GitHub settings as required/expected.
There was a conflict due to a typo fix that just got merged so I rebased. As far as I'm reading, merging might actually remove the required 3.6 checks rather than having to edit the repo settings 🙂
No, the merge can only be done after "required" checks are successful. So this requires updating settings.
@ofek Question for the future:
If we wanted to update opentelemetry-instrumentation to use pyproject.toml, according to PEP621:
Build back-ends MUST raise an error if the metadata defines a [project.entry-points.console_scripts] or [project.entry-points.gui_scripts] table, as they would be ambiguous in the face of [project.scripts] and [project.gui-scripts], respectively.
What would be your recommendation in how to define an entry point with the console_scripts table? Just project.scripts?
[project.scripts]
opentelemetry-instrument = "opentelemetry.instrumentation.auto_instrumentation:run"
opentelemetry-bootstrap = "opentelemetry.instrumentation.bootstrap:run"
[project.entry-points.opentelemetry_environment_variables]
instrumentation = "opentelemetry.instrumentation.environment_variables"
@srikanthccv @ocelotl
Looks like Github is expecting for the Python3.6 test to run to pass status checks but we removed them from the build matrix in this PR. Should we remove Python3.6 from preventing builds passing?
Yes, I was wondering if there is way to continue run tests for 3.6 but that doesn't seem possible.
Yes, I was wondering if there is way to continue run tests for 3.6 but that doesn't seem possible.
Well, metrics is already stable, so we are ready to remove support for 3.6. I would prefer to first remove support for 3.6 and update our build system to use 3.7 in a separate PR just for clarity in our history, since dropping support for 3.6 is important for our users. I'll update #2360.
This one? #2763
Yes, I am working right now on making the test cases pass there.
@ofek The PR that dropped support for py36 is merged. Please resolve the conflicts and we can get this merged.