When trying to publish, get git: recoverEncode: invalid argument (invalid character)

[bbarker]

This is the repo at 5b2d8004ed3c3945464e86701170b407b1a8c114

<previous run omitted here except:>

[error] A new bower.json has been generated. Please commit this and run `bump-version` again.
brandon@59e086953990:/wd$ spago bump-version --no-dry-run 0.0.1
[info] Generating a new Bower config using the package set versions..
[info] Generated a valid Bower config using the package set
[info] No git version tags found, so assuming current version is v0.0.0
[info] ** Running action: write the new config to the `bower.json` file and try to install its dependencies
[info] Writing the new Bower config to "bower.json"
[info] Running `bower install` so `pulp publish` can read resolved versions from it
? Answer 

[info] ** Running action: create (locally) the new git tag "v0.0.1"
spago: git: recoverEncode: invalid argument (invalid character)

[bbarker]

Normal tag creation works on the same repo:

$ git tag -a v0.0.1 -m "testing creation of tag v0.0.1"
$ git tag
v0.0.1

[bbarker]

Forgot to mention this is Spago version 0.12.1.0

[bbarker]

I'll just note that doing the following allowed a publsh to work:

1. doing the manual tagging above
2. doing a manual bower install and resolving dependency conflicts manually (not covered in the spago readme)

[f-f]

I don't seem to be able to reproduce, but I found similar issues in the Stack repo, e.g. commercialhaskell/stack#793

One of the proposed solutions there is:

export LC_ALL=C.UTF-8

@bbarker can you try this one? (and/or other solutions proposed in the thread there?)

[bbarker]

Confirmed that doing export LC_ALL=C.UTF-8 works in that case. Out of curiosity and to refresh my memory perhaps, what is the reason spago uses something other than the other alternative that works above, like:

git tag -a v0.0.1 -m "testing creation of tag v0.0.1"

[f-f]

@bbarker that's in fact the command that Spago uses to create a tag:
https://github.com/spacchetti/spago/blob/dc8a4b12b2bf25f8657e74a42ba2d55e3c63e41d/src/Spago/Git.hs#L41

..though I suspect it does it without a populated environment, which it might be the reason why you get a different result.

In any case, given that the solution proposed above works, I guess the solution is to inject LC_ALL=C.UTF-8 into the environment when calling git.
(If anyone wants to implement a fix, you might want to take a look at RIO.Process, which is what I wanted to replace all the Turtle-process stuff, since it seems a bit more versatile)