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
Metadata updates prior to version 0.2.0 #629
Metadata updates prior to version 0.2.0 #629
Conversation
We originally kept our installation directions in this file, but have since moved the information to our docs directory. We kept this file in case it was linked to from anywhere else on the World Wide Web, but it has been a long enough time that we can safely remove it.
Hello @namurphy! Thanks for updating your pull request. Congratulations! There are no PEP8 issues in this pull request. 😸 Comment last updated at 2019-05-31 02:15:59 UTC |
If I were to access the personnel record of a certain Star Fleet android, would I be looking up the...wait for it...metaData? |
35caa92
to
d7eabfe
Compare
A recommended practice for scientific reproducibility is to cite the specific version of software used for a project, and an established practice is to cite a paper or informational resource that describes it. This commit updates CITATION.rst and the near-identical docs/about/citation.rst to include both of these references. We previously decided to keep both of these files despite the duplication to make it extra apparent how to cite PlasmaPy. I changed plasmapy.__citation__ to be a list of DOI links, including the standard reference from 2018 and version 0.2.0. The metadata for our releases on Zenodo could potentially change (for example, adding the name of a contributor that wasn't known before), so a DOI is the most robust way to go about it. I reserved the DOI for version 0.2.0 on Zenodo, so the links to that will not work yet.
Incidentally, it feels a little strange to have just "force-pushed" a rebase after referencing Star Trek, not Star Wars. |
Codecov Report
@@ Coverage Diff @@
## master #629 +/- ##
======================================
Coverage 96.5% 96.5%
======================================
Files 52 52
Lines 4551 4551
======================================
Hits 4392 4392
Misses 159 159
Continue to review full report at Codecov.
|
Version 0.2.0 of PlasmaPy may be cited using the following reference. | ||
|
||
* PlasmaPy Community et al. (2019). *PlasmaPy version 0.2.0*, Zenodo, | ||
https://doi.org/10.5281/zenodo.3235817 |
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 guess thi-
I reserved the DOI for version 0.2.0 on Zenodo, so the links to that
will not work yet.
this answers my question! Good thinking.
__citation__ = [ | ||
"https://doi.org/10.5281/zenodo.1238132", | ||
"https://doi.org/10.5281/zenodo.3235817", | ||
] |
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'm of two minds about this one - on the one hand, this is the first usage of __citation__
I've seen that isn't basically a BibTeX entry. On the other, this provides easy (if multi-step) access to other citation methods here.
I guess it's fine, but I'll just note how much I'd love it to be able to do something like the following
for imported_package in ag("~/scientific_software", "import (.*)"):
try:
print(imported_package.__citation__)
except AttributeError:
pass
for future publications. But that's way out of scope of this issue 😺
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 was looking this up recently if there were any standards and came across adrn/CitationPEP#2 which suggests creating a type for citations that can handle the different citation possibilities. The loop you suggested could also probably be done if CodeMeta files become standardized and widely used (#622).
@@ -19,7 +19,7 @@ math_requires = mpmath | |||
physics_requires = lmfit | |||
|
|||
# version should be PEP386 compatible (http://www.python.org/dev/peps/pep-0386) | |||
version = 0.1.1.dev | |||
version = 0.2.0.dev |
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.
Thanks for remembering about this one! Wouldn't want to miss it later today :)
* Remove obsolete top-level INSTALL.md file We originally kept our installation directions in this file, but have since moved the information to our docs directory. We kept this file in case it was linked to from anywhere else on the World Wide Web, but it has been a long enough time that we can safely remove it. * Update setup.cfg * Update citation information A recommended practice for scientific reproducibility is to cite the specific version of software used for a project, and an established practice is to cite a paper or informational resource that describes it. This commit updates CITATION.rst and the near-identical docs/about/citation.rst to include both of these references. We previously decided to keep both of these files despite the duplication to make it extra apparent how to cite PlasmaPy. I changed plasmapy.__citation__ to be a list of DOI links, including the standard reference from 2018 and version 0.2.0. The metadata for our releases on Zenodo could potentially change (for example, adding the name of a contributor that wasn't known before), so a DOI is the most robust way to go about it. I reserved the DOI for version 0.2.0 on Zenodo, so the links to that will not work yet.
I updated some of the information about PlasmaPy in
setup.cfg
and the information on how to cite PlasmaPy (in particular by saying that users should cite both the specific version of PlasmaPy, as well as our standard informational reference from last year).I also changed
plasmapy.__citation__
to be a list of DOI links, partially because the metadata for a Zenodo upload has the potential to change, and DOIs are the most robust identifiers. Another possibility would be to include a link to the directions in our documentation, though this approach might be prone to bit rot when releases become old in case we ever reorganize our docs.