#104 AttributeError: 'module' object has no attribute '_nsgroup' with complex restriction/extension layout

[Peter Keller]

I have a set of schemata with complex circular dependencies (minimal example attached). Generating the API with a command like this works:

pyxbgen --module-prefix=com.example.pyxb --binding-root=modules --schema-root=XSD \
  --schema-location=ModelA/AA.xsd --module=ModelA.AA \
  --schema-location=ModelB/BB.xsd --module=ModelB.BB

with the following output:

urn:uuid:6099ae54-d7ad-11e0-872a-7071bcccf487
Holding incomplete resolution http://www.example.com:ModelB/BB
Holding incomplete resolution http://www.example.com:ModelA/AA
Attempting group at modules/com/example/pyxb/_nsgroup.py
Attempting group at modules/com/example/pyxb/_nsgroup.py
Importing to NM:http://www.example.com:ModelA/AUXAA@com.example.pyxb.modela._au from NGM:com.example.pyxb._nsgroup
Importing to NM:http://www.example.com:ModelA/AA@com.example.pyxb.ModelA.AA from NGM:com.example.pyxb._nsgroup
Importing to NM:http://www.example.com:ModelB/AUXBB@com.example.pyxb.modelb._a from NGM:com.example.pyxb._nsgroup
Importing to NM:http://www.example.com:ModelB/BB@com.example.pyxb.ModelB.BB from NGM:com.example.pyxb._nsgroup
Python for http://www.example.com:ModelA/AA requires 6 modules
Saved binding source to modules/com/example/pyxb/modela/_au.py
Saved binding source to modules/com/example/pyxb/ModelA/AA.py
Saved binding source to modules/com/example/pyxb/_nsgroup.py
Saved binding source to modules/com/example/pyxb/modelb/_a.py
Saved binding source to modules/com/example/pyxb/ModelB/BB.py
Saved binding source to modules/com/example/pyxb/_nsgroup.py

but I cannot import the modules. This code:

1 2 3 4 5 6 7 8

#!/usr/bin/python import sys sys.path.append("modules") import pyxb.utils.domutils as domutils import com.example.pyxb.ModelA.AA import com.example.pyxb.ModelB.BB

fails as follows:

Traceback (most recent call last):
  File "test-pyxb.py", line 8, in <module>
    import com.example.pyxb.ModelA.AA
  File "modules/com/example/pyxb/ModelA/AA.py", line 17, in <module>
    import com.example.pyxb._nsgroup
  File "modules/com/example/pyxb/_nsgroup.py", line 696, in <module>
    BASE_ClassBC._AddElement(pyxb.binding.basis.element(pyxb.namespace.ExpandedName(None, u'Property'), com.example.pyxb._nsgroup.TypeAA, scope=BASE_ClassBC))
AttributeError: 'module' object has no attribute '_nsgroup'

Although the relationships amongst the schemata are fairly complex, I do not believe that they contain errors. XMLBeans generates a Java API without any problems.

One thing that I noticed (which may or may not be relevant) is that the _nsgroup.py file is saved to twice, and contains two sets of import blocks, with the second containing this about half-way through the file:

# Import bindings for schemas in group
import pyxb.binding.datatypes
import com.example.pyxb._nsgroup

I have only seen this where the API also gives the import error.

[Peter Keller]

• attachment _pyxb-ticket104.tgz_ added

Example schemata, generation script and test python script

[Peter A. Bigot]

• status changed from new to closed
• resolution set to fixed
• milestone changed from PyXB 1.1.2 to PyXB 1.1.3

There were indeed two problems: writing different bindings to the same file, which I separated as #105, and an inadequate approach to resolving dependencies.

I've verified that the bindings now generated can be loaded, but have not attempted to use them. If you are comfortable using git, please try branch next of <git: pyxb.git.sourceforge.net="" gitroot="" pyxb=""> and let me know whether that fixes the problem for you. This ticket tipped the balance, and I'll expedite finally getting 1.1.3 out. </git:>

commit e22e0bf655dceb4c8760f50008d12b6dcdb9c934
Author: Peter A. Bigot <pabigot@‌>
Date: Mon Sep 5 14:57:56 2011 -0500

trac/104 error resolving circular dependencies

Due to cycles in the component dependency graph among namespaces, the
example schema in this ticket could improperly fail to resolve, depending on
the order in which the namespaces were attempted. Augment the unresolved
component infrastructure to retain references to components on which
resolution depends; resolve independent sibling namespaces first, and allow
for the possibility that multiple iterations through the set will be
required before all dependencies can be resolved.

[Peter A. Bigot]

And: Thank you very much for providing a complete reproducing test case.

[Peter Keller]

I've tried the "next" branch from git on the schemata that I was having problems with, and the problem seems to be fixed. I have not done extensive testing, but I am able to import modules and instantiate objects.

Looking forward to the 1.1.3 release.

Many thanks for the fix.