duplicate nodes in cff file #37
Comments
|
Hi @dpprdan Thanks for the feedback. Indeed, the duplication is intended for a single reason: In short: Adding What happens is that, if no @software{Lisa_My_Research_Software_2017,
author = {Lisa, Mona and Bot, Hew},
doi = {10.5281/zenodo.1234},
month = {12},
title = {{My Research Software}},
url = {https://github.com/github/linguist},
version = {2.0.4},
year = {2017}
}
So this cff: renders on GitHub as @article{Lisa_My_awesome_research_2021,
author = {Lisa, Mona and Bot, Hew},
doi = {10.0000/00000},
journal = {Journal Title},
month = {9},
number = {1},
pages = {1--10},
title = {{My awesome research software}},
volume = {1},
year = {2021}
}
Hope this provides an understanding of why |
|
Thanks @dieghernan for the explanation! First off, my main point (which, after reading my post again, may not have been entirely clear) was that there are some duplicate nodes under cffr::cff_create(system.file("DESCRIPTION", package="cli"), dependencies = FALSE)
#> cff-version: 1.2.0
#> message: 'To cite package "cli" in publications use:'
#> type: software
#> license: MIT
#> title: 'cli: Helpers for Developing Command Line Interfaces'
#> version: 3.3.0
#> abstract: 'A suite of tools to build attractive command line interfaces (''CLIs''),
#> from semantic elements: headings, lists, alerts, paragraphs, etc. Supports custom
#> themes via a ''CSS''-like language. It also contains a number of lower level ''CLI''
#> elements: rules, boxes, trees, and ''Unicode'' symbols with ''ASCII'' alternatives.
#> It support ANSI colors and text styles as well.'
#> authors:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> preferred-citation:
#> type: manual
#> title: 'cli: Helpers for Developing Command Line Interfaces'
#> authors:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> version: 3.3.0
#> abstract: 'A suite of tools to build attractive command line interfaces (''CLIs''),
#> from semantic elements: headings, lists, alerts, paragraphs, etc. Supports custom
#> themes via a ''CSS''-like language. It also contains a number of lower level ''CLI''
#> elements: rules, boxes, trees, and ''Unicode'' symbols with ''ASCII'' alternatives.
#> It support ANSI colors and text styles as well.'
#> repository: https://CRAN.R-project.org/package=cli
#> repository-code: https://github.com/r-lib/cli
#> url: https://cli.r-lib.org
#> identifiers:
#> - type: url
#> value: https://github.com/r-lib/cli#readme
#> date-released: '2022-04-25'
#> contact:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> keywords:
#> - cli
#> - r
#> license: MIT
#> year: '2022'
#> repository: https://CRAN.R-project.org/package=cli
#> repository-code: https://github.com/r-lib/cli
#> url: https://cli.r-lib.org
#> date-released: '2022-04-25'
#> contact:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> keywords:
#> - cli
#> - r
#> identifiers:
#> - type: url
#> value: https://github.com/r-lib/cli#readme
cffr::cff_create("cli", dependencies = FALSE)
#> cff-version: 1.2.0
#> message: 'To cite package "cli" in publications use:'
#> type: software
#> license: MIT
#> title: 'cli: Helpers for Developing Command Line Interfaces'
#> version: 3.3.0
#> abstract: 'A suite of tools to build attractive command line interfaces (''CLIs''),
#> from semantic elements: headings, lists, alerts, paragraphs, etc. Supports custom
#> themes via a ''CSS''-like language. It also contains a number of lower level ''CLI''
#> elements: rules, boxes, trees, and ''Unicode'' symbols with ''ASCII'' alternatives.
#> It support ANSI colors and text styles as well.'
#> authors:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> preferred-citation:
#> type: manual
#> title: 'cli: Helpers for Developing Command Line Interfaces'
#> authors:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> year: '2022'
#> notes: R package version 3.3.0
#> url: https://CRAN.R-project.org/package=cli
#> repository: https://CRAN.R-project.org/package=cli
#> repository-code: https://github.com/r-lib/cli
#> url: https://cli.r-lib.org
#> date-released: '2022-04-25'
#> contact:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> keywords:
#> - cli
#> - r
#> identifiers:
#> - type: url
#> value: https://github.com/r-lib/cli#readmeI think both should yield the same The above only applies when there is no `CITATION` file found.BTW, the End-of-main-issue Only then I thought "why is there a I gather now that GitHub renders a So I wondered "why would GitHub create an invalid Bibtex entry type in the first place? Shouldn't this be fixed on their end, then?" Turns out that the ruby-cff gem that GitHub uses to parse the CITATION.cff and create the other citation formats, switched from
|
|
So I see here two issues: 1. Should
|
I am not on board yet (but I don't have to 😄, just giving another perspective) These are my reasons:
Finally, regarding
The point of {cffr} is to create a CITATION.cff file. So there really is no equivalent to "no CITATION present", because we now have a CITATION.cff, which has all citation info with or without |
|
Good points: From the CFF perspective I agree on all that. And your last point seems very valid also to me:
So I would switch cffr to create There is another point then and I would like to gather your opinion here: some installed packages (namely Thanks for your feedback |
Isn't this the default behaviour, i.e. that auto-citations are always produced if no CITATION file is present? From the
Do you have an example where there is no CITATION file and no auto-citation info is produced by
I'd say it shouldn't. Because this is the one derived from the info in DESCRIPTION, which
I am seeing (with cff 0.2.2) cli_cff <- cffr::cff_create(system.file("DESCRIPTION", package="cli"))
cli_cff$`preferred-citation`
#> type: manual
#> title: 'cli: Helpers for Developing Command Line Interfaces'
#> authors:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> version: 3.3.0
#> abstract: 'A suite of tools to build attractive command line interfaces (''CLIs''),
#> from semantic elements: headings, lists, alerts, paragraphs, etc. Supports custom
#> themes via a ''CSS''-like language. It also contains a number of lower level ''CLI''
#> elements: rules, boxes, trees, and ''Unicode'' symbols with ''ASCII'' alternatives.
#> It support ANSI colors and text styles as well.'
#> repository: https://CRAN.R-project.org/package=cli
#> repository-code: https://github.com/r-lib/cli
#> url: https://cli.r-lib.org
#> identifiers:
#> - type: url
#> value: https://github.com/r-lib/cli#readme
#> date-released: '2022-04-25'
#> contact:
#> - family-names: Csárdi
#> given-names: Gábor
#> email: csardi.gabor@gmail.com
#> keywords:
#> - cli
#> - r
#> license: MIT
#> year: '2022'But like I said, I think there shouldn't be a |
|
I think #38 is ready, Basically, # devtools::install()
library(cffr)
packageVersion("cffr")
#> [1] '0.2.3.9000'
# Package with CITATION file
e1 <- cff_create("jsonlite")
cff_validate(e1)
#>
#> cff_validate results-----
#> Congratulations! This cff object is valid
e1$`preferred-citation`
#> type: article
#> title: 'The jsonlite Package: A Practical and Consistent Mapping Between JSON Data
#> and R Objects'
#> authors:
#> - family-names: Ooms
#> given-names: Jeroen
#> email: jeroen@berkeley.edu
#> orcid: https://orcid.org/0000-0002-4035-0289
#> journal: arXiv:1403.2805 [stat.CO]
#> year: '2014'
#> url: https://arxiv.org/abs/1403.2805
# Now using system.file
e2 <- cff_create(system.file("DESCRIPTION", package = "jsonlite"))
identical(e1, e2)
#> [1] TRUE
# Package without CITATION file
e3 <- cff_create("cli")
cff_validate(e3)
#>
#> cff_validate results-----
#> Congratulations! This cff object is valid
e3$`preferred-citation`
#> NULL
# Now using system.file
e4 <- cff_create(system.file("DESCRIPTION", package = "cli"))
identical(e3, e4)
#> [1] TRUE
# Dev package with CITATION file
e5 <- cff_create(dependencies = FALSE)
e5$`preferred-citation`
#> type: article
#> title: 'cffr: Generate Citation File Format Metadata for R Packages'
#> authors:
#> - family-names: Hernangómez
#> given-names: Diego
#> email: diego.hernangomezherrero@gmail.com
#> orcid: https://orcid.org/0000-0001-8457-4658
#> doi: 10.21105/joss.03900
#> url: https://doi.org/10.21105/joss.03900
#> year: '2021'
#> publisher:
#> name: The Open Journal
#> volume: '6'
#> issue: '67'
#> journal: Journal of Open Source Software
#> start: '3900'Created on 2022-08-29 with reprex v2.0.2 |
|
Awesome, thanks a lot! |
* Improve preferred-citation * Create preferred-citation only if a CITATION file is detected #37 * Update docs with pkgdev * Fix Roxygen warning Co-authored-by: dieghernan <dieghernan@users.noreply.github.com>
When
cff_create()ing a cff file from a DESCRIPTION file (either locally from an in-development package or from a path (see below)) some node duplicates are created under thepreferred-citationnode, e.g.keywords,license,contactorabstract.Session info
additional examples:
This does not happen, when there is a
CITATIONfile in the repo (i.e. it has a proper preferred citation) or whencff_create()is run on a locally installed package.`cff_create()` run locally, {tidygeocoder} has a CITATION file
`cff_create()` an installed package
Have you thought about omiting the
preferred citationaltogether if there is no CITATION file? I think apreferred citationthat effectively just duplicates the info from the main entry doesn't add much value.The text was updated successfully, but these errors were encountered: