Add MySQL and Postgres port precedence tests; refactor environment variable checks

[shaunagm]

What is this change?

• Introduced tests for MySQL and Postgres to verify that the MYSQL_PORT and PGPORT environment variables correctly override default and explicit port settings.
• Refactored database connection classes to utilize a new check_env utility for environment variable retrieval, enhancing error handling and code clarity.
• Updated relevant imports across multiple files to support the new environment variable checking mechanism.

Considerations for discussion

Likely some merge conflicts with #1826. I can wait for that PR to merge and resolve conflicts before merging.

Breaking Changes

Does this PR introduce breaking changes?

• label: Breaking change — This PR introduces one or more breaking changes.
• label: Non-breaking change — This PR does not introduce one or more breaking changes.

Details (if needed)

Technically the change in how port defaults/parameters is resolved is a breaking change. Previously, PGPORT/MYSQL_PORT env variables were effectively ignored when port wasn’t passed, because the port parameter defaults to an integer which evaluates as truthy. So port or os.environ.get("PGPORT") always used 5432 even when no parameter was passed and a PG_PORT env variable was set.

If anyone was relying on the default port number passed into the mysql or postgres connectors overriding an environmental variable, then they would experience a breaking change. Although it seems pretty odd that someone would set an environmental variable but rely on it being overridden? So I'm not too concerned.

But will ship this with other breaking changes and name it in the release notes just to be cautious.

EDIT: I changed my approach to be less of a breaking change. But it is still a very very slight breaking change.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
parsons/aws
s3.py					32-35
parsons/azure
azure_blob_storage.py					52-55
parsons/box
box.py					67-70
parsons/databases/mysql
mysql.py
parsons/databases/postgres
postgres.py
parsons/databases/redshift
redshift.py
parsons/facebook_ads
facebook_ads.py					83-89
parsons/mobilize_america
ma.py
parsons/notifications
slack.py
parsons/salesforce
salesforce.py
Project Total

This report was generated by python-coverage-comment-action

[bmos]

Feel free to merge before #1826, any conflicts should be minimal.
This is great!

[bmos]

Import sorting is a ruff check feature, for whatever reason.

[shaunagm]

Updated my approach. It bothered me that someone passing in the default port would have it overridden, so I set the default port to None and put the default in the init code itself.

So now:

• if you don't pass in anything or set an env variable, the default is still used
• if you don't pass in anything but do set an env variable, the env variable is used
• if you pass in something (whether it's identical to the default or not) that gets used

Still technically a breaking change but it's so hard to imagine why someone would have their system set up in a way that this would break it so.

[bmos]

That is actually how the check function works.
If you passed in an argument, it uses that instead of the environment variable. The environment variable is just the fallback.

That's why I refactored it and documented it in a pull request, it was kind of hard to understand.

[shaunagm]

@bmos I was referring there to the behavior of the MySQL/Postgres connector __init__ functions in my last comment, not to check_env. But yes I agree, we do want the behavior of those functions to be in line with the behavior of check_env for consistency. Before my most recent update, someone passing in a port to __init__ would have had it overridden by the environmental variable if it happened to be the same as the default, which seems like not ideal behavior.