Attempt to lock down dependencies

relrod commented 2 months ago

In the current world, we do not lock down dependencies at all. This means that developers are all potentially developing against moving targets, and some dependencies from which we subclass models could generate migrations (which could be backwards incompatible and cause issues for environments that use system packages pinned to older versions).

In this commit is really 3 changes:

Update the updater script a bit - let it write out all the DAB application .txt files
Make pyproject.toml use those .txt files
Add current working/known upper bounds to all deps where possible before generating the .txt files.

I believe this is the first step towards sanity here and vision into which versions of dependencies are getting pulled in and where.

In the current world, we have a dep that released a new z-stream release which changed a field in a baseclass we're using. For developers who got that new version of the library (since we don't pin deps currently), it is easy to think that we need to push the new migration that gets generated. However we have no idea currently if that change would be compatible with apps using DAB, or apps forced to use the old version of the dependency due to system packages.

sonarcloud[bot] commented 2 months ago

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

shanemcd commented 2 months ago

Thank you for doing this @relrod .

ansible / django-ansible-base

Attempt to lock down dependencies #585

Quality Gate passed