Defined all colors used in the admin CSS as variables. Implemented the
following standardizations and accessibility improvements while at it:
- Improved the contrast of text to not use ratios of less than 3:1 anymore.
- Most hover states already used desaturated and darkened colors.
Changed object tools to follow the same rule instead of showing the
primary color on hover.
Various places used similar colors; those have been merged with the goal
of reducing the count of CSS variables. Contrasts have been improved in
a few places.
- Many borders used slightly different colors (e.g. #eaeaea vs. #eee)
- Help texts used #999, this has been changed to --body-quiet-color
(#666) which has a better contrast.
Introduced fast color transitions on links and buttons.
django.utils.autoreload.get_child_arguments() detected when Python was
started with the `-m` option only for `django` module. This commit
changes the logic to check __spec__, see
https://docs.python.org/3/reference/import.html#main-spec
Now packages can implement their own __main__ with the runserver
command.
Previously load_backend() performed search by computing the (sole)
entry of django.db.backends.__path__ manually from
django.db.utils.__file__. Now django.db.backends.__path__ is used
directly.
The migrations loader prevents the use of PEP-420 namespace packages
for holding apps' migrations modules. Previously the loader tested for
this only by checking that app.migrations.__file__ is present. This
prevented migrations' being found in frozen Python environments that
don't set __file__ on any modules. Now the loader *additionally* checks
whether app.migrations.__path__ is a list because namespace packages
use a different type for __path__. Namespace packages continue to be
forbidden, and, in fact, users of normal Python environments should
experience no change whatsoever.
Argon2 encodes the salt as base64 for representation in the final hash
output. To be able to accurately return the used salt from decode(),
add padding, b64decode, and decode from latin1 (for the remote
possibility that someone supplied a custom hash consisting solely of
bytes -- this would require a manual construction of the hash though,
Django's interface does not allow for that).
The field is ignored server-side and only exists as a client-side
convenience. Removing it slightly simplifies the documentation and
avoids some distractions.
Added note:: for MIN_NUM_FORMS/MAX_NUM_FORMS in
Understanding the management form section.
Co-authored-by: Carlton Gibson <carlton.gibson@noumenal.es>