fidzu : debian

My blog post about my Red Hat shell prompt proved very popular, although some people tried my instructions and couldn't get it to work, so here's some further information.

The unicode code-point I am using is "🎩", U+1F3A9 TOP HAT. My Terminal font of choice is Noto Mono Regular which does not contain a glyph for that code-point. Therefore the font system my Terminal uses (pango) is pulling it from another font. In my case, it's using OverPass Mono, an open source font created for Red Hat branding. The TOP HAT glyph in OverPass Mono is a Fedora. This is a nice little easter egg included by the font authors. (There's at least one other easter egg in the font, by the way!)

It's pure chance that my font system chose OverPass Mono to pull that glyph.

The simplest way to get this to work is (probably) to download and install "OverPass Mono" and set your Terminal font to it for all characters. Alternatively you may need to look at configuring Pango (or whatever font system you are using).

If your Terminal and font system support multicolour emojis, then the above alone may not work for you. Some of my colleagues got a nasty surprise when upgrading their systems: their red hats turned blue. It's possible to add a trailing Unicode modifying code-point that instructs the font system to not render the prior glyph using multicolour emojis. This reportedly fixes it:

hat="🎩"
combiner="$(perl -CS -e 'print "\N{VARIATION SELECTOR-15}"')"
# ^ alternatively, "$(printf '\xef\xb8\x8e')"
export PS1="\[\e[31m\]${hat}${combiner}\[\e[0m\]"

(Thanks ilmari for the perl trick)

17 Jan 2019 4:57pm GMT

Today I'm glad to announce that my new book, Serious Python, has been released.

However, you wonder… what is Serious Python?

Well, Serious Python is the the new name of The Hacker's Guide to Python - the first book I published. Serious Python is the 4th update of that book - but with a brand a new name and a new editor!

For more than a year, I've been working with the editor No Starch Press to enhance this book and bring it to the next level! I'm very proud of what we achieved, and working with a whole team on this book has been an amazing experience.

The content has been updated to be ready for 2019: pytest is now a de-facto standard for testing, so I had to write about it. On the other hand, Python 2 support was less a focus and I removed many mention of Python 2 altogether. Some chapters have been reorganized, regrouped and others got enhanced with new content!

The good news: you can get this new edition of the book with a 15% discount for the next 24 hours using the coupon code SERIOUSPYTHONLAUNCH on the book page.

The book is also released as part as No Starch collection. They also are in charge of distributing the paperback copy of the book. If you want a version of the book that you can touch and hold into your arms, look for it in No Starch shop, on Amazon or in your favorite book shop!

No Starch version of the cover for Serious Python

17 Jan 2019 4:56pm GMT

The Symfony project has recently created a set of pure-PHP polyfills for both PHP extensions and newer language features. It allows developers to add requirements upon those functions or language additions without increasing the system requirements upon end users. For the most part, I think this is a good thing, and valuable to have. We've done similar things inside MediaWiki as well for CDB support, Memcached, and internationalization, just to name a few.

But the downside is that on platforms where it is possible to install the missing PHP extensions or upgrade PHP itself, we're shipping empty code. MediaWiki requires both the ctypes and mbstring PHP extensions, and our servers have those, so there's no use in deploying polyfills for those, because they'll never be used. In September, Reedy and I replaced the polyfills with "unpolyfills" that simply provide the correct package, so the polyfill is skipped by composer. That removed about 3,700 lines of code from what we're committing, reviewing, and deploying - a big win.

Last month I came across the same problem in Debian: #911832. The php-symfony-polyfill package was failing tests on the new PHP 7.3, and up for removal from the next stable release (Buster). On its own, the package isn't too important, but was a dependency of other important packages. In Debian, the polyfills are even more useless, since instead of depending upon e.g. php-symfony-polyfill-mbstring, the package could simply depend upon the native PHP extension, php-mbstring. In fact, there was already a system designed to implement those kinds of overrides. After looking at the dependencies, I uploaded a fixed version of php-webmozart-assert, filed bugs for two other packages. and provided patches for symfony. I also made a patch to the default overrides in pkg-php-tools, so that any future package that depends upon a symfony polyfill should now automatically depend upon the native PHP extension if necessary.

Ideally composer would support alternative requirements like ext-mbstring | php-symfony-polyfill-mbstring, but that's been declined by their developers. There's another issue that is somewhat related, but doesn't do much to reduce the installation of polyfills when unnecessary.

17 Jan 2019 7:50am GMT