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

[1.3] Version handling, parser fixes, setup update #197

Merged
merged 23 commits into from
Dec 12, 2017

Conversation

mpsonntag
Copy link
Contributor

This PR introduces the following changes to the 1.3 branch:

  • [Doc format] Provides a package and a document format version number in the new file info.py
  • [Doc format] All parsers now use the common document format version number.
  • [Doc format] When trying to open a file with any of the odml parsers, first the document format version number is checked. If the found version number does not match the supported one, file loading will fail an exception, since this is the oldest format version. If anyone tries to open a newer format, they should first update their odml package and not use this one...
  • [Doc saving] An odML document can now only be saved, if the validation does not show any errors. Saving an invalid document will exit while printing all encountered errors.
  • [Parser loading] All parsers are now more relaxed when encountering unsupported tags or missing tags and only print warnings instead of ending with an exception. Warnings are collected and can be accessed via the parser object (required for display in odml-ui to avoid potential loss of information).
  • [Setup] now contains updated authors, contact, website, license and classifiers.
  • Cherry picks from the development branch to address fileio/odmlparser error when loading JSON or YAML #191 and odmlparser error on section attributes #194 also in the 1.3 branch.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 80.419% when pulling 64a91d5 on mpsonntag:picks into fea65ed on G-Node:version_1.3.

Copy link
Member

@jgrewe jgrewe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 80.419% when pulling 2415055 on mpsonntag:picks into fea65ed on G-Node:version_1.3.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 80.419% when pulling c8e6157 on mpsonntag:picks into fea65ed on G-Node:version_1.3.

Copy link
Member

@achilleas-k achilleas-k left a 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.

"""
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
Copy link
Member

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.

accepted as a valid odML file.
"""
if root.tag != 'odML':
raise ParserException("Expecting <odML> start tag but got <%s>.\n" % root.tag)
Copy link
Member

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 ".

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")
Copy link
Member

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
Copy link
Member

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.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 80.419% when pulling c2ae4b5 on mpsonntag:picks into fea65ed on G-Node:version_1.3.

@achilleas-k achilleas-k merged commit bf88a3c into G-Node:version_1.3 Dec 12, 2017
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

Successfully merging this pull request may close these issues.

4 participants