On Tue 2017-01-03 14:20:43 -0500, anarcat wrote:
> I'm happy to follow whatever upstream decides, but I'd like to point out
> that this is not just a feature request ("non-ASCII wordlist", which can
> be supported fine even if we go back to py2 btw), but an actual bug
> ("fails to work").
"fails to work when the user explicitly sets LANG=C on a program that
deals with human-readable text in 2017" :)
> C.UTF-8 is necessarily available on all Debian systems, let alone the
> default. In fact, I believe the default locale, on Debian systems, is
> still C. Having our package fail to work in that locale breaks the
> Principle Of Least Astonishment.
I don't think this is the case, but i could be wrong. What makes you
think that this is true? the default for debian systems is to install
a task-$LANGUAGE package based on the choice made during d-i, and
configures a sensible localse C.UTF-8
is always available.
I do note that when LANG is completely unset, we see the same failure,
even though C.UTF-8 is available. In that case, i'd recommend that we
just explicitly set LANG=C.UTF-8 (within wormhole) to work around
python-click's idiosyncracies on py3.
But if the user deliberately sets LANG=whatever to something
non-unicode, i don't think it's unreasonable for wormhole to decline to
work in that environment if one of its dependencies is dependent on a
UTF-8 locale.
> I still believe the simplest fix, in the short term, is to revert back
> packaging to Python2. We could (and should, anyways) provide both
> python2 and python3 bindings for the magic-wormhole *libraries* and make
> the binary use the python2 libraries until the click bug is fixed or
> Debian defaults to a UTF-8 locale.
why not just (a) fix the unset $LANG situation with a small patch, and
(b) tag the python-click bug as "affects: magic-wormhole" and leave it
as is?
--dkg
signature.asc
Description: PGP signature
