Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serialize the API? #6

Open
rpgoldman opened this issue Jun 2, 2021 · 3 comments
Open

Serialize the API? #6

rpgoldman opened this issue Jun 2, 2021 · 3 comments
Milestone

Comments

@rpgoldman
Copy link

Is there some way to serialize the API produced by the sbol factory as python source code?

If not, that would be a great addition to the library.

@bbartley
Copy link
Contributor

There isn't currently a good way to do that. There is however a verbose option which will tell you about the data model that is being generated. This may provide some insight whether the ontology file is being interpreted and translated into an API correctly.

__factory__ = SBOLFactory(locals(), 
                          posixpath.join(os.path.dirname(os.path.realpath(__file__)),
                                         'paml.ttl'),
                          'http://bioprotocols.org/paml#', verbose=True)

This outputs something like this:

SubProtocol
---------
	instance_of	Protocol	1	1

Protocol
------
	material	Component	0	inf
	activities	Activity	0	inf
	locations	Location	0	inf
	output	ProtocolPinSpecification	0	inf
	flows	Flow	0	inf
	input	ProtocolPinSpecification	0	inf

Which tells you each class, property, and cardinality of the property that is parsed from the OWL file and translated into a Python class definition.

The goo of a generated API is based on pySBOL3. All the generated classes extend the core classes of that library. So if you understand the patterns of pySBOL3, you will understand the generated API as well.

@rpgoldman
Copy link
Author

I was telling @jakebeal that my bias working in software is one of pessimism: always assume that it's not going to work for someone and think about how they are going to debug when it happens.

This applies double to code generation frameworks, because the programmer is typically completely helpless when things go wrong. Even monkey-patching is difficult if the API artifact is ephemeral.

In addition, having to constantly regenerate the API is going to incur an unnecessary startup cost.

I strongly urge you prioritize this enhancement for the SBOL factory.

/cc @danbryce

@rpgoldman
Copy link
Author

/cc @jgladwig

@jakebeal jakebeal added this to the Future Tasks milestone Oct 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants