Legal API - Upgrade to python 3.13 and use common lear packages (model, etc.)
- Dominant language
- JavaScript
- Stars
- 23
- Forks
- 62
- Avg merge
- 24m
- Merged PRs (30d)
- 1
Description
## Background
- During the GCP migration the other lear backend services were upgraded to python 3.13, but the legal-api is still on 3.9
- Several pieces of code were extrapolated out of the legal-api into common packages which are used in the other lear backend services, but the legal-api is not using them. Currently when we need to update these we have to update it in both the legal-api and the common packages, and there is some drift accumulating. The major concern here is the db model
## Plan for tickets
- ~Remove minio references in the legal-api (everything should be using DRS now)~ - *can't remove - still relying on it for a few flows*
- Remove db-versioning FF in the legal-api (it is on in all environments and the common model does not support dual versioning) - *confirmed with argus we can do this*
- Use common code packages instead of local copy - *need to discuss upgrading python before or after this - currently not all common packages support python 3.9*
- maybe new release branch with legal-api on python 3.13 with upgraded deps
- use business-registry-common
- will replace local legal-api copies of: BaseEnum, BaseMeta, datetime, LegislationDatetime
- update business-registry-common for any missing functionality
- common LegislationDatetime needs format_as_report_string_with_custom_time, format_as_report_expiry_string_1159, format_as_legislation_date, is_future
- update legal-api imports and verify
- small update / low risk
- use business-registry-account
- will replace AccountService used in legal_api/services/bootstrap.py
- update business-registry-common to include 'get_contacts' first
- small update / low risk
- use business-registry-model
- replaces the legal-api's models
- will need to take a close look at any drift across the two and apply updates to the common model as needed (i.e. recently a minor update to share_class in legal-api was not applied to business-registry-model)
- alembic migration versions should be in sync - need to verify how the CD is upgrading the db and update it if needed
- major update / high risk
- use business-registry-dissolution
- replaces InvoluntaryDissolutionService inside legal_api/services/involuntary_dissolution.py
- note: has model dependency and flags dependency should be reviewed
- use business-registry-digital-credentials
- replaces services/digital_credentials*.py in legal-api
- ~~may be some drift between valid_role_types and ALLOWED_DBC_ACCOUNT_ROLES to reconcile~~ [LO: unified this in https://github.com/bcgov/lear/pull/4390]
- note: has model dependency
- Release plan (Testing plan etc.)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the legal-api service paths named in the plan, especially legal_api/services/bootstrap.py, legal_api/services/involuntary_dissolution.py, and services/digital_credentials*.py, then compare their local implementations with the common packages. Verify Python 3.13 dependencies, model drift, db-versioning removal, and Alembic synchronization. Done means the legal-api uses the common packages and the release and testing plan is confirmed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, databases
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100