Request: release a patch version that pins cython<3.0

[gwerbin]

Currently, it's impossible to build Pyproj 3.6.0 with PEP 517 build isolation because Pip will install Cython 3.x, which Pyproj 3.6.0 is incompatible with.

This can be easily fixed by releasing a Pyproj 3.6.1 or 3.6.0.post1 version that does simply adds <3.0 to the Cython build dep: https://github.com/pyproj4/pyproj/compare/3.6.0...gwerbin:pin-cython-below-3.0?expand=1

I understand that the current master branch updates Pyproj to use only Cython 3.x, but I'm not aware of a release date for it. This patch would be very useful for end users who need to build their own wheels (e.g. for PyPy), while the next release is still in development.

[snowman2]

For most projects, a release is fairly simple as you mention. However, due to a requirement on maintainers free time, building wheels, and testing with downstream Linux release managers, it is not quite as simple for pyproj.

The next release of pyproj depends on python 3.12 compatibility updates from a release from numpy to ensure stability.

We welcome assistance preparing pyproj for the next release with Python 3.12 wheels.

[gwerbin]

@snowman2 thanks for the reply. Is it a matter of someone running through the release instructions here? Or is there more to it? I'm happy to dedicate some time to the patch release, unless the next real release of Pyproj is right around the corner.

[snowman2]

The blocker for the next release is #1330. Once that is ready, the release will follow. That likely depends on the next release of numpy, but there may be a way to get it to work now.

The instructions you linked to are correct. However, slightly out of date. The wheels are automatically uploaded except from Cirrus CI as those need to be manually uploaded to pypi currently.

[djhoese]

@snowman2 I had some luck with the vispy project (builds wheels with a single Cython extension) with forcing the pre-release of numpy to be installed. I see you're already doing that, but it looks like for some reason it is trying to build numpy from source. Here's vispys cibuildwheel env vars:

https://github.com/vispy/vispy/blob/a1a639f33c59a16c8af2bf605a23b55210569f5e/.github/workflows/wheels.yml#L38-L39

If needed I can try to take a look tomorrow, but no guarantees on time. I also don't build 32-bit wheels for vispy (or any of my packages) and it looks like you do...how do you handle that with numpy not providing 32-bit wheels?

[snowman2]

I think that it is the pypy wheels and win32 wheels that are building from source. Depending on the win32 failures, that one would be okay to disable.

[snowman2]

There are suggestions for workarounds linked in #1330 to numpy issues.

[djhoese]

My kid had to stay home sick today so I'm not really getting any work done today and probably not tomorrow.

[snowman2]

No worries @djhoese. I hope that your kid feels better soon.

[snowman2]

Coming soon ... #1344

[gwerbin]

Thanks @snowman2! I would still be happy to help with patch or "post" releases for older versions for the sake of any users who can't upgrade for whatever reason. In my case, updating to the newest version is fine.

[snowman2]

https://pypi.org/project/pyproj/3.6.1/

[snowman2]

I would still be happy to help with patch or "post" releases for older versions for the sake of any users who can't upgrade for whatever reason.

Contributions to help with releases are welcome 👍

[djhoese]

@snowman2 could you point me to the release instructions? In your opinion what is the hardest part? Would you consider pyproj's release process much harder than other python packages you maintain (ex. rioxarray) given how tightly it is tied to the PROJ library? Or are there other reasons?