Binding to a type in the same package as generated code produces invalid output #283
Comments
|
This is such a weird coincidence! I just started working on a PR for this 😅 However, my PR currently deals with it from the Will link it here as soon as the tests are done and we can see if it's enough. |
|
Ah, good find! I think the ideal place to update this would be in |
|
Got a first attempt in #285. Reworked my approach to make it work with 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 |
|
Any updates on this? |
The original motivation here is to fix #283, which is that if you try to use `bindings` to bind to a type in the same package as the generated code, we generate a self-import, which Go doesn't allow. Fixing that is easy -- the three lines in `imports.go` -- once you know the package-path of the generated code. (The test that that all fits together is in integration-tests because that was the easiest place to set up the right situation.) Determining the package-path is not too much harder: you ask `go/packages`, which we already use for `package_bindings`. But once we're doing that, and handling errors, it's kinda silly that we ask you to specify the package your generated code will use, because we have that too, usually. So I rewrote that handling too, making `package` now rarely necessary (see for example the `example` config), and warning if it looks wrong. This is the changes in `config.go`, and is the more substantial non-test change. (I also renamed some of the testdata dirs to be valid package-names, to exercise more of that code, or in the case of `find-config`, just for consistency.)
…age (#316) The original motivation here is to fix #283, which is that if you try to use `bindings` to bind to a type in the same package as the generated code, we generate a self-import, which Go doesn't allow. Fixing that is easy -- the three lines in `imports.go` -- once you know the package-path of the generated code. (The test that that all fits together is in integration-tests because that was the easiest place to set up the right situation.) Determining the package-path is not too much harder: you ask `go/packages`, which we already use for `package_bindings`. But once we're doing that, and handling errors, it's kinda silly that we ask you to specify the package your generated code will use, because we have that too, usually. So I rewrote that handling too, making `package` now rarely necessary (see for example the `example` config), and warning if it looks wrong. This is the changes in `config.go`, and is the more substantial non-test change. (I also renamed some of the testdata dirs to be valid package-names, to exercise more of that code, or in the case of `find-config`, just for consistency.) I have: - [x] Written a clear PR title and description (above) - [x] Signed the [Khan Academy CLA](https://www.khanacademy.org/r/cla) - [x] Added tests covering my changes, if applicable (and checked that the test for the bugfix fails without the rest of the changes) - [x] Included a link to the issue fixed, if applicable - [x] Included documentation, for new features - [x] Added ~an entry~ two entries to the changelog
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.
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.
The text was updated successfully, but these errors were encountered: