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

Build with PEP 517, move project metadata to pyproject.toml #84

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

EpicWink
Copy link
Contributor

@EpicWink EpicWink commented Aug 3, 2022

  • Drop Python 2.7, 3.5 and 3.6 support (pyproject.toml support in setuptools requires a version which only supports Python 3.7+), including wheel builds in CI
  • Remove download-URL

* Enable PEP 517 builds
* Remove download-URL
* Remove unused 'ctypes' dependency
* Remove empty accelerate requirements file
* Remove '..' from accelerate include-dirs
@EpicWink EpicWink changed the title Move project metadata pyproject.toml Move project metadata to pyproject.toml Aug 3, 2022
These are ignored anyway, as the build is in an isolated environment
Hopefully will fix TOML parsing errors
Earliest version with pyproject.toml support
Copy link

@ChrisBarker-NOAA ChrisBarker-NOAA left a comment

Choose a reason for hiding this comment

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

Just a coupole minor points.

Thanks!

.travis.yml Outdated Show resolved Hide resolved
accelerate/pyproject.toml Show resolved Hide resolved
@EpicWink
Copy link
Contributor Author

Just a coupole minor points.

These changes are not necessary for the goal of this PR (which is to move project metadata to pyproject.toml), and therefore out of scope. In the interest of minimising the changes in a PR, I would say to make those changes in a new PR

@ChrisBarker-NOAA
Copy link

Well, updating the Python versions supported i part of this PR -- so I'd at least do that.

As for the Cython dependency, fixing that kind of thing seems pretty in scope to me, and it would just get tangled up to do a PR on the old code, 'cause then when this got merged, it would break it again.

But it's your PR.

@ChrisBarker-NOAA
Copy link

I've done: #86

@mcfletch
Copy link
Owner

I'd be unhappy dropping Python 2.7 support without bumping the major release version.

My intention is to continue supporting (for some value of support defined based on my rather scant spare time) Python 2.7 with PyOpenGL until the EOL for support on the RHEL/Centos platform, which IIRC is June 2024. At that point I'll likely do a Python 2.7 incompatible release with type declarations etc. as a PyOpenGL 4.x release.

Python 3.6 was default in Ubuntu Bionic, which EOL's 6 years from now. I'm not super worried about supporting Bionic itself, as I doubt it's got a big market share among those doing 3D graphics with raw OpenGL, but it does seem we're being rather aggressive in dropping support for OSes that are quite recent/new.

I'll try to find time to review the particular changes in the pull request over the next two days before I need to return to paying work. I expect much of the build-system cleanup (it's quite hoary after 20+ years of development) at least can be pulled in while still supporting 2.7 and 3.6 .

@EpicWink
Copy link
Contributor Author

EpicWink commented Aug 29, 2022

@mcfletch see PR #85, which is similar but without dropping the Python version support

In the meantime, I'm working on another PR which moves CI to GitHub Actions (to enable cibuildwheel)


Python 3.6 was default in Ubuntu Bionic, which EOL's 6 years from now.

Ubuntu LTS release (such as Bionic 18.04) have a 5 year support term, with a 5-year extension only for paying customers. This means Bionic will be EOL next year (2023). I don't think any open-source library should support releases which are privately supported.

@khimaros
Copy link

khimaros commented Sep 13, 2022

this is currently blocking installation of p5 module on debian 11

@ChrisBarker-NOAA
Copy link

3.6 is no longer supported by Python.org -- I don't see why downstream projects should have to support Python versions that are no longer supported upstream.

I've never understood why folks want to ru an old OS, and old version of Python, but need the latest third-party package (e.g pyOpenGL, numpy what have you).

Anyway: there's also no reason to gratuitously drop older versions -- if it works with old versions, then might as well call it supported. But if any real updating will be done -- dropping old versions can be really nice and keep things simpler.

@khimaros: what is the actual blocker here? what might be a solution?

This PR is updating the build system -- the old one should still work.

@khimaros
Copy link

khimaros commented Sep 15, 2022

@ChrisBarker-NOAA the PyOpenGL-Accelerate 3.1.6 release fixes this issue with python3.10 #74 and is currently not available for linux, i believe blocked on this merge request.

i filed an issue with the downstream library here for tracking: p5py/p5#395

@ChrisBarker-NOAA
Copy link

got it -- That's really #37 -- but yes, this PR would help fix that too.

@EpicWink EpicWink changed the title Move project metadata to pyproject.toml Build with PEP 517, move project metadata to pyproject.toml Sep 26, 2022
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.

None yet

4 participants