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

Multiple DOIs per atomtype #168

Merged
merged 7 commits into from
Aug 17, 2018
Merged

Conversation

summeraz
Copy link
Contributor

Currently the doi attribute for atomtypes defined in a force field XML file only supports a single DOI. However, there may be instances where multiple DOIs would be appropriate (see #158). This PR adds support for listing multiple DOIs within the doi attribute, and passes this information through to the BibTeX file that is created.

@summeraz summeraz added this to the 0.5 milestone May 30, 2018
Copy link
Member

@ctk3b ctk3b left a comment

Choose a reason for hiding this comment

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

Nice! Just some minor suggestions

@@ -721,14 +723,16 @@ def _write_references_to_file(self, atom_types, references_file):
warnings.warn("Reference not found for atom type '{}'."
"".format(atype))
unique_references = collections.defaultdict(list)
for key, value in atomtype_references.items():
unique_references[value].append(key)
for key, values in atomtype_references.items():
Copy link
Member

Choose a reason for hiding this comment

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

Could we update these to be for atomtype, dois in ...?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

with open(get_fn('ethane-multi.bib')) as file1:
with open('ethane-multi.bib') as file2:
diff = difflib.ndiff(file1.readlines(), file2.readlines())
changes = [l for l in diff if l.startswith('+ ') or l.startswith('- ')]
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So I had initially tried using filecmp when writing this test for mBuild; however, I ran into an issue with Appveyor (https://ci.appveyor.com/project/ctk3b/mbuild-o0viu/build/1.0.755#L1137). I think because filecmp performs a binary comparison there is an issue that arises when comparing files generated on MacOS/Linux and on Windows (see https://bugs.python.org/issue6306).

Copy link
Member

Choose a reason for hiding this comment

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

Ah I see - makes sense. If there is no diff, couldn't you simply assert not diff? Or will it always contain something? Is it just a header that you can unambiguously strip?

Regardless of the above, I would de-dent the changes = ... and assert lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

diff will show all lines, with a + in front of lines that are unique to file2 and a - in front of lines that are unique to file1. So changes is just stripping out only those lines that are different between the two files. I actually got this from this StackOverflow answer.

Copy link
Member

Choose a reason for hiding this comment

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

Heh alright this isn't really that essential but one last suggestion: https://docs.python.org/2/library/difflib.html#difflib.unified_diff and just set n=0 to get no context lines! 🎉

Copy link
Contributor Author

Choose a reason for hiding this comment

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

🍾 Ah, nice suggestion! It seemed like there had to be a better way to compare two files.

@summeraz summeraz merged commit e3c3a74 into mosdef-hub:master Aug 17, 2018
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.

2 participants