Binding to a type in the same package as generated code produces invalid output

[mathewbyrne]

Describe the bug Binding to a type in the same package as the generated file is not detected and results in an import loop as the package is import itself.

To Reproduce Output the generated file in the same location as a bound type.

generated: db/generated.go
bindings:
  FilterType:
    type: github.com/mathewbyrne/project/db.Filter

Expected behavior The generated output should not have any import statement, as the type is in the same package. The type should be used directly without reference to it's package.

genqlient version 0.6

Additional context Working around this is fairly simple by placing the generated output in a sub-package, but this still seems like a bug that could be resolved.

[costela]

This is such a weird coincidence! I just started working on a PR for this :sweat_smile:

However, my PR currently deals with it from the package_bindings side, using a "magic" . package. The more general solution of matching the package path more intelligently requires a bit more refactoring - I think.

Will link it here as soon as the tests are done and we can see if it's enough.

[benjaminjkraft]

Ah, good find! I think the ideal place to update this would be in generator.ref/generator.addImportFor? Those should be able to see whatever we know about the current package and just have a special case. (But somewhere you may have to figure out -- or ask Go -- what the full package path for the current package even is.)

[costela]

Got a first attempt in #285.

Reworked my approach to make it work with bindings + package_bindings equally well.

Getting the fully qualified package is a bit fiddly and I'm not entirely sure it's "safe" (it relies on relative imports, which AFAICT have a rocky support history). But is seems to work.

PTAL

[mwajeeh]

Any updates on this?