Consider removing upper bounds from dependencies in setup.py

[jhkennedy]

harmony-py currently pins its core (and develop) dependencies down to compatible releases, specified all the way down to a specific patch set in some instances.

Since Python has a flat dependency tree (can't have two versions of the same package in an environment) and harmony-py is a library^, not an application, this is overly restrictive.

For example, python-dotenv is pinned to ~=0.20.0 or >=0.20.0,==0.20.* which was released two years ago and is a major version behind (current v1.0.1). If any package in a user's environment depends on python-dotenv>=0.21.0, harmony-py cannot be installed.

There's an excellent long-form discussion of upper bounds here: https://iscinumpy.dev/post/bound-version-constraints/

Notably, this problem also exists with over-constrained lower bounds, although it's less problematic over time.

I'd suggest including the dependencies directly in the project metadata (setup.py/setup.cfg/pyproject.toml) and only excluding known incompatibilities with version bounds, and only migrating bounds when new incompatibilities are discovered or resolved.

For development, it's still often desirable to have a known working environment for developers, which is where requirements.txt files come into play.

While this requires some duplication as new requirements must be added to both the project metadata and the development environment specification, that cost significantly improves the usability of the library.

---

^ Here, I'm using a common generalization of "library" and "application" to primarily distinguish between how packages are installed into environments and who owns said environments.

• Library: intended to be installed into user environments alongside whatever packages are in their environments. The more restrictive the version bounds, the less likely it is possible to install the package in user environments, and the primary responsibility of the dependency bounds, in this case, is to say, "This package will not work with these package versions."
• Application: intended to be installed into environments/infrastructure that the developers own and maintain but users do not have access to, and must work so dependencies are strictly specified so that the environment is known to work.

[vinnyinverso]

I created a JIRA ticket to address this. We'll also provide updates/feedback here as needed. Thanks for the detailed suggestion!

HARMONY-1837