Change to not re-export any SBOL symbols from OPIL

[jakebeal]

Right now, the OPIL package uses a wildcard export of symbols, which includes all of the SBOL symbols imported as well as internal materials that might not want to be exposed. It would be better to have the factory track the specific symbols that are being created for export.

[bbartley]

This is not quite correct. OPIL only uses a wildcard symbol to export all the classes generated from the factory file (because it is not possible to explicitly know these a priori and hardcode these exports). OPIL does not export all of the SBOL symbols. It only selectively exposes those SBOL symbols that are required to create coherent OPIL data structures, e.g., Measure and then exposes those symbols publicly through the API. (These symbols, while public through the OPIL API, are still bound to the sbol3 scope.). Ultimately, this makes the library more convenient to use as a standalone package.

[jakebeal]

This might be my naivete in Python, but I'm really liking the clean distinction in my programs of using an "sbol3.Component" rather than an "opil.Component", since it's not really part of OPIL. Mixing the namespaces makes me feel uneasy, since I've gotten burned by that so many times in other languages.

[jakebeal]

Conclusion of discussion: import nothing from OPIL, because we are redirecting the core document functions to SBOL

[bbartley]

See also https://docs.python.org/3/tutorial/modules.html#importing-from-a-package

[bbartley]

This is mostly resolved in https://github.com/SD2E/opil/pull/173. However OPIL still exports and requires use of a specialized Document class to enable SHACL validation. This is related to https://github.com/SynBioDex/pySBOL3/issues/197

[bbartley]

Closing now, as #158 concerns deprecating opil.Document in favor of sbol.Document