Announcing the release of Blue version 0.5.1
==== Blue ====
What is blue? =============
``blue`` is a somewhat less uncompromising code formatter than ``black``, the OG of Python formatters. We love the idea of automatically formatting Python code, for the same reasons that inspired ``black``, however we take issue with some of the decisions ``black`` makes. Kudos to ``black`` for pioneering code formatting for Python, and for its excellent implementation.
Where the ``blue`` maintainers disagree with the stylistic (and unconfigurable) choices made by ``black``, we monkeypatch to change these decisions to our own liking. We intend for these differences to be minimal; even in cases where we'd prefer something different, there's a lot we can live with for the sake of consistency.
We'd prefer not to fork or monkeypatch. Instead, our hope is that eventually we'll be able to work with the ``black`` maintainers to add just a little bit of configuration and merge back into the ``black`` project. We'd be ecstatic if ``blue`` eventually were retired. Until then, we'll maintain our small set of hacks on top of ``black`` and carefully consider what other deviations are needed to assuage our sensitive, but experienced, eye.
How do I use blue? ==================
Exactly the same as you would use ``black``. Invoke and configure ``blue`` as you would ``black`` -- just replace the ``black`` command with ``blue``, sit back, and enjoy even betterly formatted Python code! You can refer to `black's https://black.readthedocs.io/en/stable/`_ documentation for anything not listed here.
So what's different? ====================
Here is a brief list of differences between ``blue`` and ``black``:
* ``blue`` defaults to single-quoted strings. This is probably the most painful ``black`` choice to our eyes, and the thing that inspired ``blue``. We strongly prefer using single quoted strings over double quoted strings for everything *except* docstrings. Don't ask us why we prefer double quoted strings for docstrings; it just looks better to us! For all other strings, ``blue`` defaults to single quoted strings.
* ``blue`` defaults to line lengths of 79 characters. Nearly every project creates a pyproject.toml just to change this one setting so making it consistent with PEP 8 seems relatively harmless.
We are `accumulating https://github.com/grantjenks/blue/issues/2`_ a list of other deviations we are considering. As we decide to implement any particular suggestion, we'll turn those into individual issues and tackle them one-by-one. If you have suggestions for other deviations from ``black``'s choices, please open a separate ticket on our tracker, and we'll see how it goes!
Why "blue"? ===========
Several reasons! If your formatter is going to beat up your code, it'll leave it black and blue, or maybe in this case, black *or* blue. Blue is better!
We also thought about "tan" because, yum! But that project name was already taken. Frankly, "blue" was also taken, but largely unused. Our thanks to Nick Ficano for donating the project namespace to us!
Blue is also the color of `LinkedIn https://www.linkedin.com/`_, the authors' gracious employer, and we intend to socialize its use within our company code base.
``blue`` thanks this list of contributors for all its wonderful goodness.
* The `wonderful folks https://github.com/psf/black#authors`_ from the ``black`` project.
* Grant Jenks * Barry Warsaw
``blue`` is licensed under the terms of the Apache License Version 2.0. ``black`` is `licensed https://github.com/psf/black#license`_ under the terms of the MIT license.
Project details ===============
* Project home: https://github.com/grantjenks/blue * Report bugs and suggestions at: https://github.com/grantjenks/blue/issues * Code hosting: https://github.com/grantjenks/blue.git * Documentation: https://blue.readthedocs.io/en/latest
I'm pleased to announce the release of Django-Compat-Patcher 0.10, which now includes 67 compatibility shims ranging from Django 1.6 to 3.1
If your Django project is incompatible with a useful pluggable app, or if you encounter the depths of dependency hell when attempting to mass-upgrade your packages, no panic!
Just drop the django compatibility patcher into your project, and keep your developments going forward, while dependency conflicts are slowly sorted out in bugtrackers.
As a proof-of-concept, the Pychronia alternate reality portal is kept perfectly functional on Django 3.1.5, while still having Django 1.10 constructs like "views as dotted strings" (but don't do that for your own projects, alternative tools like django-compat or django-codemod can help you migrate your own codebase).
Enjoy your decade-long backwards compatibility (and get in touch if some compatibility shims are missing for you)
Project homepage : https://github.com/pakal/django-compat-patcher Download : https://pypi.org/project/django-compat-patcher/0.10/
PS: latest versions of Pip, with the improved dependency solver, might block on theoretical dependency conflicts even though Django-Compat-Patcher solved them; then you might have to keep using an older Pip version, or bypass the Pip dependency resolver, until some escape hatches are implemented in it.