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

Use compile_time_env in place of shims #2016

Merged
merged 6 commits into from
Feb 18, 2021

Conversation

snowman2
Copy link
Member

@snowman2
Copy link
Member Author

Can the GDAL 1.x stuff be removed?

@sgillies
Copy link
Member

@snowman2 unfortunately I didn't warn about dropping support for GDAL 1.x when we released 1.1.0. I think we had better keep it around for one more minor version.

@sgillies
Copy link
Member

@snowman2 I like simplicity! But we do have some complex needs. We currently include 4 shim .c modules in our source distributions. Will these directives cover our need to be able to build against 4 different categories of GDAL versions from one source distribution?

@snowman2
Copy link
Member Author

Will these directives cover our need to be able to build against 4 different categories of GDAL versions from one source distribution?

That is a good point to bring up. This would probably make cython required to build rasterio from sdist. This shouldn't be an issue with the pyproject.toml file. pyproj has required cython or pip>=10.0.1 since version 2 and haven't had any complaints yet.

Relevant files:

With all of that in place, it should support various versions of GDAL from a single sdist. But, definitely should do some testing to ensure everything works as expected.

That also means this PR likely needs some tweaks.

@sgillies
Copy link
Member

@snowman2 let's do this after 1.2.0. It's close and I don't want to add anything else and risk pushing it out further.

@snowman2
Copy link
Member Author

With #2064, the GDAL 1.x stuff can be removed. Correct?

@snowman2 snowman2 force-pushed the compile_time_env branch 2 times, most recently from 24dc498 to 8e16e0a Compare December 30, 2020 01:53
@snowman2
Copy link
Member Author

With #2064 I was able to remove the shim files entirely and move things into their respective modules. Seems the only compatibility stuff left is GDAL 3 related.

@snowman2
Copy link
Member Author

@sgillies any blockers remaining?

@sgillies
Copy link
Member

@snowman2 I'll look at this soon. I need to switch my open source attention to fiona and shapely for a bit, but will get back to rasterio soon.

@sgillies
Copy link
Member

I've branched main-1.2 off of the master branch and will review this first thing tomorrow.

@sgillies
Copy link
Member

@snowman2 have you seen https://mail.python.org/archives/list/python-dev@python.org/message/2K3IKBD4K7INMVV3LK6SJY6EXDDNC2M2/? It's an author of Cython arguing for not making Cython a build dependency. I do appreciate not having to deal with unknown versions of Cython on user systems.

@snowman2
Copy link
Member Author

@sgillies, that is definitely an interesting discussion he has there. He has some valid concerns. But, he does also lay out some reasons why you would want to have cython as a build dependency.

For the downsides he has mentioned, I have yet to run into them with pyproj, and it has been a couple of years now. It may be because most users use wheels, conda, or the linux distro install methods most of the time. From my understanding, this is the case for rasterio as well. So, it sounds like if you do depend on cython, it will be for a minority of users that actually compile rasterio from source. And of those users, there is a slight possibility that something might go wrong when cython compiles it due to an outdated version. From my perspective, that is a risk worth accepting.

For the upside of using cython, I see 2:

  1. The simplifications introduced in this PR which makes future changes and bugfixes easier
  2. "you may end up with a setting in which your code
    adapts also to newer environments, by using a recent Cython version
    automatically."

Side note: The current build from source method for rasterio always uses cython using modern pip due to pyproject.toml and the logic to use cython in setup.py if it is present. If that is not desired, some changes are likely needed.

@sgillies
Copy link
Member

Yeah, the author doesn't mention build isolation or the fact that we can pin the cython version in pyproject.toml (like https://github.com/pyproj4/pyproj/blob/master/pyproject.toml#L3). I'm more in favor but still want to reflect on this a bit.

@@ -36,3 +36,6 @@ cdef class DatasetBase:
cdef const char *get_driver_name(GDALDriverH driver)
cdef OGRSpatialReferenceH _osr_from_crs(object crs) except NULL
cdef _safe_osr_release(OGRSpatialReferenceH srs)
cdef void osr_set_traditional_axis_mapping_strategy(OGRSpatialReferenceH hSrs)
cdef const char* osr_get_name(OGRSpatialReferenceH hSrs)
cdef GDALDatasetH open_dataset(object filename, int mode, object allowed_drivers, object open_options, object siblings) except NULL
Copy link
Member

Choose a reason for hiding this comment

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

👍

IF CTE_GDAL_MAJOR_VERSION >= 3:
OSRSetAxisMappingStrategy(hSrs, OAMS_TRADITIONAL_GIS_ORDER)
ELSE:
pass
Copy link
Member

Choose a reason for hiding this comment

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

👍

paths = CSLAddString(paths, path_c)
OSRSetPROJSearchPaths(paths)
ELSE:
os.environ["PROJ_LIB"] = path
Copy link
Member

Choose a reason for hiding this comment

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

👍

'-o', 'rasterio/_shim30.c'])

print(_)
sdist.run(self)
Copy link
Member

Choose a reason for hiding this comment

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

👋

Copy link
Member

@sgillies sgillies left a comment

Choose a reason for hiding this comment

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

@snowman2 alright, let's do this! Thank you very much.

@sgillies sgillies added this to the 1.3.0 milestone Feb 18, 2021
@sgillies sgillies merged commit 99511e4 into rasterio:master Feb 18, 2021
@snowman2 snowman2 deleted the compile_time_env branch February 18, 2021 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants