[SYSADMIN ACTION][Dependency] Bump sqlalchemy from 1.4.29 to 2.0.41 in /.setup/pip

[dependabot]

Please see the release notes:
https://submitty.org/sysadmin/installation/version_notes/v25.07.01

Bumps sqlalchemy from 1.4.29 to 2.0.40.
In order to test this PR, you would need to run submitty_install_bin as the dependencies are not updated when you run submitty_install
Related to Submitty/submitty.github.io#692

Release notes

Sourced from sqlalchemy's releases.

2.0.40

Released: March 27, 2025

orm

• [orm] [bug] Fixed regression which occurred as of 2.0.37 where the checked ArgumentError that's raised when an inappropriate type or object is used inside of a Mapped annotation would raise TypeError with "boolean value of this clause is not defined" if the object resolved into a SQL expression in a boolean context, for programs where future annotations mode was not enabled. This case is now handled explicitly and a new error message has also been tailored for this case. In addition, as there are at least half a dozen distinct error scenarios for intepretation of the Mapped construct, these scenarios have all been unified under a new subclass of ArgumentError called MappedAnnotationError, to provide some continuity between these different scenarios, even though specific messaging remains distinct.

  References: #12329

• [orm] [bug] Fixed regression in ORM Annotated Declarative class interpretation caused by typing_extension==4.13.0 that introduced a different implementation for TypeAliasType while SQLAlchemy assumed that it would be equivalent to the typing version, leading to pep-695 type annotations not resolving to SQL types as expected.

  References: #12473

sql

• [sql] [usecase] Implemented support for the GROUPS frame specification in window functions by adding _sql.over.groups option to _sql.over() and FunctionElement.over(). Pull request courtesy Kaan Dikmen.

  References: #12450

• [sql] [bug] Fixed issue in CTE constructs involving multiple DDL _sql.Insert statements with multiple VALUES parameter sets where the bound parameter names generated for these parameter sets would conflict, generating a compile time error.

  References: #12363

• [sql] [bug] Fixed regression caused by #7471 leading to a SQL compilation issue where name disambiguation for two same-named FROM clauses with table aliasing in use at the same time would produce invalid SQL in the FROM clause with two "AS" clauses for the aliased table, due to double aliasing.

... (truncated)

Commits

• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[rafizamankhan]

@dependabot rebase

[codecov]

Codecov Report

❌ Patch coverage is 42.85714% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.72%. Comparing base (26ad49e) to head (add0c57).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #11578      +/-   ##
============================================
+ Coverage     20.56%   21.72%   +1.15%     
- Complexity     9282     9303      +21     
============================================
  Files           268      268              
  Lines         35574    35696     +122     
  Branches        457      457              
============================================
+ Hits           7317     7755     +438     
+ Misses        27804    27488     -316     
  Partials        453      453              

Flag	Coverage Δ
autograder	21.31% <5.88%> (-0.04%)	⬇️
js	2.09% <ø> (ø)
migrator	100.00% <100.00%> (ø)
php	20.62% <ø> (+1.38%)	⬆️
python_submitty_utils	80.08% <ø> (ø)
submitty_daemon_jobs	88.88% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dependabot]

A newer version of sqlalchemy exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged.

[williamschen23]

@dependabot recreate

[jeffrey-cordero]

This may require updates to the existing submitty_install script or some sort of system admin logic because I always get the following error, but it's resolved on pip3 install sqlalchemy==2.0.41 - this would also fix the existing failing DB Check test.

Checking for system and database migrations
Running up migrations for master...Traceback (most recent call last):
  File "/usr/local/submitty/GIT_CHECKOUT/Submitty/migration/run_migrator.py", line 9, in <module>
    cli.run(sys.argv[1:], config_path)
  File "/usr/local/submitty/GIT_CHECKOUT/Submitty/migration/migrator/cli.py", line 94, in run
    getattr(main, args.command)(args)
  File "/usr/local/submitty/GIT_CHECKOUT/Submitty/migration/migrator/main.py", line 171, in migrate
    handle_migration(args)
  File "/usr/local/submitty/GIT_CHECKOUT/Submitty/migration/migrator/main.py", line 214, in handle_migration
    migrate_environment(
  File "/usr/local/submitty/GIT_CHECKOUT/Submitty/migration/migrator/main.py", line 323, in migrate_environment
    if database.has_table(database.migration_table.__tablename__):
  File "/usr/local/submitty/GIT_CHECKOUT/Submitty/migration/migrator/db.py", line 102, in has_table
    self.inspector.clear_cache()
AttributeError: 'PGInspector' object has no attribute 'clear_cache'

[williamschen23]

@jeffrey-cordero migrations run before we install the new packages for the checkout. I'm not sure if this is iin the scope of this pr

[jeffrey-cordero]

@jeffrey-cordero migrations run before we install the new packages for the checkout. I'm not sure if this is iin the scope of this pr

Should be in the scope of the PR as DB Check will fail until it's resolved. We should be updating / installing missing dependencies as needed given the migrations require the right version of SQLAlchemy.

[williamschen23]

@jeffrey-cordero migrations run before we install the new packages for the checkout. I'm not sure if this is iin the scope of this pr

Should be in the scope of the PR as DB Check will fail until it's resolved. We should be updating / installing missing dependencies as needed given the migrations require the right version of SQLAlchemy.

db check will fail regardless. It only checks out main's dependencies and will fail regardless of if install is fixed or not. Barb said that it is fine if db check fails

[jeffrey-cordero]

@jeffrey-cordero migrations run before we install the new packages for the checkout. I'm not sure if this is iin the scope of this pr

Should be in the scope of the PR as DB Check will fail until it's resolved. We should be updating / installing missing dependencies as needed given the migrations require the right version of SQLAlchemy.

db check will fail regardless. It only checks out main's dependencies and will fail regardless of if install is fixed or not. Barb said that it is fine if db check fails

Makes sense, but this will require a manual installation to ensure submitty_install works, so the PR description should be updated. The package installation on GitHub Actions will resolve once this is merged into main, but I suppose if any other issues exist (I can't get the workflow running locally through Docker), someone else will address them.

[lavalleeale]

Code change looks good to me, everything that can be the same is and everything that can't is as close as possible and should have the same functionality

[williamschen23]

@jeffrey-cordero im still getting an error for sending emails when i do vagrant up. Can you verify if this is happening on your end too? It says that the directory should be chown -R submitty_daemon directory but the first files in there are owned by root.

[jeffrey-cordero]

@jeffrey-cordero im still getting an error for sending emails when i do vagrant up. Can you verify if this is happening on your end too? It says that the directory should be chown -R submitty_daemon directory but the first files in there are owned by root.

This is not occurring on my end. I have no issues releasing emails through send_email.py and send_notification.py. If this has anything to do with the previous commit, make sure you run submitty_install, but if the directories already exist, just delete them before running the command, just in case.

[jeffrey-cordero]

The changes implemented for the update to SQLAlchemy v2 look solid based on the recommended migration strategy. The only inconsistencies I could spot were related to fixing existing errors or removing old columns that are no longer referenced in the respective tables. The setup, database, and shared binary scripts behave as expected after a fresh vagrant up.