-
Notifications
You must be signed in to change notification settings - Fork 30
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
[1.3] Version handling, parser fixes, setup update #197
Conversation
Added author list, contact, classifiers, license text and updated the provided hompage for future packaging.
For now when xmlparser is used from odmlparser, all unsupported or missing element errors are warnings to allow parsing of partially invalid odML documents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Couldn't find any serious issues, so had to nitpick typos instead.
The import cycle issue can be fixed in a later PR since it will require a bit more work than just moving around a file.
odml/tools/xmlparser.py
Outdated
""" | ||
Check if the odML version of a handed in parsed lxml.etree is supported | ||
by the current library and raise an Exception otherwise. | ||
:param root: Root node of a parsed lxml.etree. Teh root tag has to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I appreciate a nice "Teh", I think in this case it's an actual typo.
odml/tools/xmlparser.py
Outdated
accepted as a valid odML file. | ||
""" | ||
if root.tag != 'odML': | ||
raise ParserException("Expecting <odML> start tag but got <%s>.\n" % root.tag) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we call it an open instead of a start tag? I think people tend to say "open a X tag". Or maybe we can say neither and just have it say "Expecting tag but got ".
odml/tools/xmlparser.py
Outdated
raise ParserException("Expecting <odML> start tag but got <%s>.\n" % root.tag) | ||
elif 'version' not in root.attrib: | ||
raise ParserException("Could not find format version attribute " | ||
"in odML start tag.\n") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
@@ -122,6 +122,17 @@ def get_values(self, value_list): | |||
return value_seq | |||
|
|||
def write_file(self, odml_document, filename): | |||
# Write document only if it does not contain validation errors. | |||
from ..validation import Validation # disgusting import problems |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to shuffle things around a bit to make this a bit more sane. It's possible to avoid this import cycle if we move the validation file to the tools
submodule, but I think we have bigger import issues. One issue is we don't use explicit relative imports everywhere. This might lead to issues when testing local code while a global version of the package is installed. It might also lead to subtle bugs where local file location are changed, but the absolute import hides this by importing from an installed version.
This leads me to a different issue I came across. We have a lot of functions in the top-level __init__.py
. This isn't a problem in and of itself, but we do import one of these functions into the validation file, which makes internal package imports impossible. So we end up with a situation where the validation file imports odml
, which relies on importing everything else, which obviously would result in an import cycle.
This PR introduces the following changes to the 1.3 branch:
info.py