Absolute import causes duplicate ID #278
Comments
|
I have no idea but maybe try to move @0x95c41c96183b9c2f; after the import in parent? |
|
FWIW it sounds like the system isn't recognizing that |
|
Does this mean that the solution may be to try omitting this line: And seeing if the import creates the Child object properly anyway? Is it possible the schema parser ultimately creates the nested objects at the same scope? |
|
No, if you need to reference |
|
Some futzing resulted in this working, although not likely what you want: with But this was the only incantation that produced what you would want here. |
|
Threw a few debugging statements into the capnp.pyx: and get the same thing over and over: I then created schemas/grandparent.capnp and tried to import GrandParent it after Parent: Then inverted the imports (so GrandParent first): Interestingly, one listed a context, and one did not. Is it possible that the SchemaParser.load method is being called and no check is being done to ensure that a particular schema isn't already loaded (perhaps by maintaining a list of @0x95 IDs seen)? |
|
When the C++ schema parser interprets the line |
|
Changing this: |
|
Yes. Thus, my current solution is to simply use relative imports, along with some hacky # __init__.py
import os
import capnp
capnp.remove_import_hook()
here = os.path.dirname(os.path.abspath(__file__))
target_definition_capnp = os.path.abspath(os.path.join(here, "target_definition.capnp"))
TargetDefinition = capnp.load(target_definition_capnp).TargetDefinition |
|
We would need to ask the C++ library if some file has already been parsed (because it was included from other file) and, instead of asking it to parse it (again), just return it. Yes, it's some missing feature on the library side. |
- Stop adding the directory of every .capnp file to the import path. If a .capnp file wants to import a file in its own directory, it should use a relative import. Fixes capnproto#278 - Stop using /usr/include/capnp as an import path. This is incorrect. It should only be /usr/include. - Stop allowing additional paths to be specified for magic imports. This leads to inconsistencies. More specifically, the way that a nested import like `ma.mb.mc_capnp` gets imported by python, is to first import `ma`, then import `ma.mb`, and finally `ma.mb.mc_capnp`. Pycapnp's magic importing is only involved in the last step. So any additional paths specified don't work for nested imports. It is very confusing to only have this for non-nested imports. Users with folder layouts that don't follow pythons import paths can still use `capnp.load(.., .., imports=[blah])`.
- Stop adding the directory of every .capnp file to the import path. If a .capnp file wants to import a file in its own directory, it should use a relative import. Fixes capnproto#278 - Stop using /usr/include/capnp as an import path. This is incorrect. It should only be /usr/include. - Stop allowing additional paths to be specified for magic imports. This leads to inconsistencies. More specifically, the way that a nested import like `ma.mb.mc_capnp` gets imported by python, is to first import `ma`, then import `ma.mb`, and finally `ma.mb.mc_capnp`. Pycapnp's magic importing is only involved in the last step. So any additional paths specified don't work for nested imports. It is very confusing to only have this for non-nested imports. Users with folder layouts that don't follow pythons import paths can still use `capnp.load(.., .., imports=[blah])`.
- Stop adding the directory of every .capnp file to the import path. If a .capnp file wants to import a file in its own directory, it should use a relative import. Fixes capnproto#278 - Stop using /usr/include/capnp as an import path. This is incorrect. It should only be /usr/include. - Stop allowing additional paths to be specified for magic imports. This leads to inconsistencies. More specifically, the way that a nested import like `ma.mb.mc_capnp` gets imported by python, is to first import `ma`, then import `ma.mb`, and finally `ma.mb.mc_capnp`. Pycapnp's magic importing is only involved in the last step. So any additional paths specified don't work for nested imports. It is very confusing to only have this for non-nested imports. Users with folder layouts that don't follow pythons import paths can still use `capnp.load(.., .., imports=[blah])`.
- Stop adding the directory of every .capnp file to the import path. If a .capnp file wants to import a file in its own directory, it should use a relative import. Fixes #278 - Stop using /usr/include/capnp as an import path. This is incorrect. It should only be /usr/include. - Stop allowing additional paths to be specified for magic imports. This leads to inconsistencies. More specifically, the way that a nested import like `ma.mb.mc_capnp` gets imported by python, is to first import `ma`, then import `ma.mb`, and finally `ma.mb.mc_capnp`. Pycapnp's magic importing is only involved in the last step. So any additional paths specified don't work for nested imports. It is very confusing to only have this for non-nested imports. Users with folder layouts that don't follow pythons import paths can still use `capnp.load(.., .., imports=[blah])`.
Hello!
I want to use multiple schema files, where one schema is a parent schema that imports a child schema. I also want to import the child schema directly for use in my Python script. I made a minimum implementation that causes the duplicate ID error. The schemas are located within a schemas subfolder.
The parent schema, located in /schemas/parent.capnp
The child schema, located in /schemas/child.capnp
The test application, located in /test.py
Running the script gives
KjException child.capnp:0: failed: Duplicate ID @0x9afc0f7513269df3.on line 3.What is causing this?
Using Python 3.8.10 on Windows, with pycapnp 1.1.0, same on Ubuntu 20.04 (same Python/pycapnp versions).
The text was updated successfully, but these errors were encountered: