search

geopython / OWSLib

OWSLib is a Python package for client programming with Open Geospatial Consortium (OGC) web service (hence OWS) interface standards, and their related content models.
https://owslib.readthedocs.io
BSD 3-Clause "New" or "Revised" License
386 stars 275 forks source link

pin requirements #565

Open tomkralidis opened 5 years ago

tomkralidis commented 5 years ago

The recent pyproj 2.0.0 release has resulted in some install issues (example: https://github.com/geopython/GeoHealthCheck/issues/240). The root cause here is that we are not pinning requirements.txt. The impact is that a given OWSLib release has less reproducibility as dependencies evolve.

On the flip side, it is valuable to not pin requirements such that we can keep builds current.

Having said this, perhaps a strategy could be to pin requirements when cutting a release and then unpinning them thereafter.

What do folks think? Are there other / better approaches?

justb4 commented 5 years ago

I would say: go for pinning using == at least for releases and then for the entire dependency chain. It's not just the build, there may be subtle functionality and even security issues (as once hit the Nodejs/npm world). In other projects, especially in Docker builds, I have even used pip freeze to generate requirements.txt for that reason. Saw some guidance here: https://nvie.com/posts/pin-your-packages/ but there may be many more. Especially with a library that many other products depend on.

ocefpaf commented 5 years ago

The issues you are seeing are probably only with pyproj 2 b/c it requires proj.4 6.0.0. So I recommend something like pyproj >=1.9,<2.

Note that the underlying proj.4 library versions used to build pyproj 1.9.* ranges from 4.9.1 to 5.2.0. An exact pin there would be quite chaotic and would force people to rebuild pyproj with many other proj.4 combinations just to satisfy the pin.

kalxas commented 5 years ago

@ocefpaf +1

huard commented 3 years ago

I second @ocefpaf. As mentioned in one reference cited above, pinning dependencies is important for end products. For libraries, it seems inadvisable to pin everything, since it would most likely conflict with other requirements from other libraries. I suggest OWSLib only pins dependencies with known incompatibilities, bugs or security issues.

ocefpaf commented 3 years ago

BTW, it was just announced that the new pip resolver will be enabled by default in the next version. Tightly pinned requirements will yield libraries quite hard to resolve and install. So having a range of known compatibility will be crucial.

github-actions[bot] commented 1 week ago

This Issue has been inactive for 90 days. In order to manage maintenance burden, it will be automatically closed in 7 days.