https://pantsbuild.org/ logo
Join Slack
Powered by
Hi all, I’m trying to get started with pants in on...
# general
l
Hi all, I’m trying to get started with pants in one of our existing repos. Following along with the getting started guide, using Go and I was able to install pants and run 
pants tailor ::
to generate my build files. But now, no matter what target I do such as 
pants check
or 
pants list
, I get a crash with the following:
Copy code
15:53:39.68 [ERROR] 1 Exception encountered:

  IncompleteJSONError: parse error: trailing garbage
          mod", 	"GoVersion": "1.19" } { 	"Path": "<http://cloud.google.com/go|cloud.google.com/go>
                     (right here) ------^
👀 1
h
I've never seen that before... Can you run with 
-ldebug
and 
--print-exception-stacktrace
so we can see more error context?
l
Sure, here’s the output from `./pants -ldebug --print-stacktrace list ::`: https://gist.github.com/jcrumb-u21/d3b575ae2b7a8ac2060c2409a0b73171 Based on some googling of the error, it looks like maybe there’s more than one top-level JSON object and 
ijson
isn’t happy about it?
On pants v2.14.0 with 
pants.backend.experimental.go
as my only backend, as well.
h
Yeah, at a glance it looks like 
go list -json
returns multiple concatenated JSON objects, and we're not handling it well in some cases
But I would have thought that this is why we're using ijson to begin with, rather than the built-in json stdlib
And indeed we set 
multiple_values=True
in ijson
Which Pants version are you on?
l
2.14.0
h
cc @fast-nail-55400
@late-keyboard-89314 Do you have a sense of which go package's JSON js triggering the issue? This will be hard to fix without a consistent reproduction
Can you share your code? Or a stripped-down version that still manifests the bug?
f
I see go 1.19 in the snippet. Is this with go 1.19?
And does the problem persist if you downgrade to Go 1.18?
Based on some googling of the error, it looks like maybe there’s more than one top-level JSON object and 
ijson
isn’t happy about it?
ijson
can handle multiple top-level objects just fine, that is why we use it since Pants knows the output has multiple top-level objects. The issue could be that the break between top-level objects is happening on the same line versus having an intervening newline between the 
} {
bit
and I suspect that this is a difference in Go 1.19's output versus earlier versions of Go
hmm 
ijson
handles newlines just fine:
Copy code
% ./pex ijson==3.1.4
Python 3.10.7 (main, Oct 30 2022, 11:30:35) [Clang 14.0.0 (clang-1400.0.29.102)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> with_newline = "{}\n{}"
>>> without_newline = "{}{}"
>>> import ijson
>>> list(ijson.items(with_newline, "", multiple_values=True))
[{}, {}]
>>> list(ijson.items(without_newline, "", multiple_values=True))
[{}, {}]
>>>
we will likely need to dive in on what exactly Go 1.19 is returning for its JSON exactly
please open an issue and include Python version, Go version, and what third-party modules your project uses. also include whether using Go 1.18 works around the problem. thanks.
also I am assuming you were using Go 1.19; this assumption could of course be false. I don't recall testing with Go 1.19 so I am assuming that is the change that contributed to the issue.
hmm and I am using Go 1.19 locally so could be third party package. Can you share your 
go.mod
? If it can't be made public on an issue, feel free to share via DM.
l
Issue created, 
go.mod
is linked there in a gist
Okay, I’ve been playing with this a bit this morning. It’s complaining right at the head of the result of 
go list
, it doesn’t make it through even one iteration. I’ve got another gist of the formatted output (generated by just writing what 
pants.backend.go.util_rules.third_party_pkg.analyze_module_dependencies
gets to a file after UTF-8 decoding. Here’s the gist (updated the issue as well): https://gist.github.com/jcrumb-u21/9c4f36108689722921dfd179e2013bd8
5 Views
Open in Slack
PreviousNext
Powered by