Hi @Zaczero - thanks for opening the issue. I appreciate the challenges that the strict dependency requirements might impose on using pypgstac within a larger project, but I have not run into that recently. Is there a particular dependency that is causing the problem in your case?

Feel free to open a pull request with the changes you described! It might be fine to open everything up with >= but I suspect there is a reason at least some of them have been pinned to specific versions.

The problem with >= is that you run into the strong possibility that you can get a breaking change in one of your dependencies.

I am also struggling with integration because of the strict dependency versions. Although I do understand @bitner's point. I do see another PR opened in December also tried to loosen some dependencies: #331. Are you more comfortable with that method that limits it to anything prior to the next major release?

@bitner

Strictly pinning minor versions (like package==1.2.3 or package==1.2.*) in Python dependencies creates unnecessary problems in real-world applications. When multiple packages in a project need different minor versions of the same dependency, this leads to "dependency hell" where pip cannot resolve the dependencies at all. This is especially problematic when your package needs to coexist with others in larger projects.

The Python ecosystem works best when packages specify reasonable version ranges (like package>=1.2). This ensures you get security patches and bug fixes while still maintaining control over major version changes. The more strictly you pin versions, the more likely your package becomes unusable as part of a larger software stack (which is the case).

Please look around the Python ecosystem, including well-established projects, and see that strict version pinning is an exception from how it's typically done. Your argument for strict pinning might make sense, but it goes against established practices in the Python ecosystem and creates real problems for users trying to integrate multiple packages together.

I suggest as a compromise package>=1.2,<2.0 to limit to the current major version, which is what https://github.com/stac-utils/pgstac/pull/331/files is doing for a couple of the packages.