This introduces beets 1.3.11, changes can be found at:
https://github.com/sampsyo/beets/releases/tag/v1.3.11
Thanks to @pjones for the pull request, which also adds him to the
maintainers.
My changes on the other hand are only of cosmetic nature and do not
change anything in functionality.
We're passing glibcLocales to the tests directly, so we don't pollute
the builder's environment anyway, so no reason to override anything
there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I know, I know, this is me being ultra-nazi about those things, but
beets is about OCDing your music collection, so why not apply this to
the Nix expressions as well?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should fix #7366 for now, but using the (IMHO) pragmatic approach
of extending the sed expression to recognize strings.
However, this approach is obviously not parsing the full AST, nor does
it wrap Python itself (as pointed out by @spwhitt in #7366) but tries to
match Python strings as best as possible without getting TOO unreadable.
We also use a little bit of Nix to help generating the SED expression,
because doing the whole quote matching block over and over again would
be quite repetitious and error-prone to change. The reason why I'm using
imap here is that we need to have unique labels to avoid jumping into
the wrong branch.
So the new expression is not only able to match continous regions of
triple-quoted strings, but also regions with only one quote character
(even with escaped inner quotes) and empty strings.
However, what it doesn't correctly recognize is something like this:
"string1" "string2" "multi
line
string"
Which is very unlikely that we'll find something like this in the wild.
Of course, we could handle it as well, but it would mean that we need to
substitute the current line into hold space until we're finished parsing
the strings, branch off to another label where we match multiline
strings of all sorts and swap hold/pattern space and finally print the
result. So to summarize: The SED expression would be 3 to 4 times bigger
than now and we gain very little from that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This partially reverts commit 3a4fd0bfc6.
Addresses another concern by @edolstra that users might not want to
update *all* channels. We're now reverting to the old behaviour but
after updating the "nixos" channel, we just check whether the channel
ships with a file called ".update-on-nixos-rebuild" and if it exists, we
update that channel as well.
Other channels than these are not touched anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
My original reason to put it at the beginning of NIX_PATH was to allow
shipping a particular version <nixpkgs> with a channel. But in order to
do that, we can still let the channel expression ship with a custom
version of nixpkgs by something like <channel/nixpkgs> and the builder
of the channel could also rewrite self-references.
So the inconvenience is now shifted towards the maintainer of the
channel rather than the user (which isn't nice, but better err on the
side of the developer rather than on the user), because as @edolstra
pointed out: Having the channels of root at the beginning of NIX_PATH
could have unintended side-effects if there a channel called nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
