pants version is 2.19.1, stacktrace is

...
"/Users/ed/Library/Caches/nce/b53192ff83dd22c11f093268f09503786fcdeb806b34ecf4d2e519c915578288/bindings/venvs/2.19.1/lib/python3.9/site-packages/pants/backend/go/util_rules/third_party_pkg.py", line 235, in analyze_module_dependencies
    version = mod_json["Replace"]["Version"]
KeyError: 'Version'

Code does ensure that

Replace

key is present, but it doesn't check for version:

for mod_json in ijson.items(mod_list_result.stdout, "", multiple_values=True):
        # Skip the first-party module being analyzed.
        if "Main" in mod_json and mod_json["Main"]:
            continue

        if "Replace" in mod_json:
            # TODO: Reject local file path replacements? Gazelle does.
            name = mod_json["Replace"]["Path"]
            version = mod_json["Replace"]["Version"]
        else:
            name = mod_json["Path"]
            version = mod_json["Version"]

I wonder if issue could be as simple that code assumes

replace

in go module has version? It is not mandatory as per https://go.dev/doc/modules/gomod-ref#replace

Found an existing ticket which is exactly the same error

Trying to find any kind of fix. Obviously most simple attempt to use

mod_json["Replace"].get("Version")

doesn't help, because

None

is not valid version identifier. Empty string (using

.get("")

doesn't help either)

Edit: seems like removing all BUILD worked, now rerunning

pants tailor ::

doesn't complain anything 🤔 Edit2: issue still remains, if I remove all buildfiles and use

pants tailor ::

to generate those, it succeeds. But if I then run

pants tailor ::

then it fails with

cannot use relative path ../<reponame>@latest

ok, found this year old thread which I interprete as follows: • Go code should not use relative paths in

replace

or • we should find people willing to work on Go part not enough familiar with Pants, so not sure where to start if I'd want to fix it. Sad in a way that relative paths are not allowed, as to me it seems like it is one reason why people create monorepos; to avoid versioning, because as long as you deploy all linked projects together in a monorepo, you don't need internal versioning of parts

I'll respond over there

@curved-hydrogen-24259 any interest still in tackling this?