Re: [Bioc-devel] Circular dependencies and vignette building

[Hervé Pagès]

Hi Jonathan,

This is indeed a very common situation and you are doing the right
thing. Please upload PCHiCdata to our issue tracker in the same issue
as Chicago. We'll make sure that the build system installs the 2
packages (Chicago and PCHiCdata, in that order) before it tries to
build Chicago.

Thanks,
H.

On 10/06/2015 09:55 AM, Jonathan Cairns wrote:

Hi,

I am attempting to submit a software package "Chicago", and a corresponding data package 
"PCHiCdata", to Bioconductor. However, I have an issue with circular dependencies.

Chicago "suggests" PCHiCdata, because one of the data sets in PCHiCdata is used to build 
the vignette. As a result, when BioC attempts to R CMD BUILD Chicago, it cannot build the vignette 
and thus returns an error. However, PCHiCdata "depends" on Chicago, because the data use 
a class from Chicago, so I can't build and install it first. (I got around this issue on my local 
machine by installing Chicago before building the vignette.)

One issue is that we found it impossible to create a data set that was small 
enough to fit in the software package, but large enough to have enough 
information to run the full Chicago workflow on. This is why the vignette 
depends on the external data package.

I imagined this situation would be common, but I couldn't find any advice on 
it. Is there a sensible/recommended way to resolve this dependency?

Thanks,

Jonathan

The Babraham Institute, Babraham Research Campus, Cambridge CB22 3AT Registered 
Charity No. 1053902.
The information transmitted in this email is directed only to the addressee. If you 
received this in error, please contact the sender and delete this email from your 
system. The contents of this e-mail are the views of the sender and do not 
necessarily represent the views of the Babraham Institute. Full conditions at: 
www.babraham.ac.uk
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] authorship and citation

[Thierry Onkelinx]

Dear Adrian,

Have a look at the DESCRIPTION of the RODBC package. One of the authors was
contributing from 1999 to 2002. I have the feeling that your situation is
similar.

Best regards,

ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey

2015-10-06 18:55 GMT+02:00 Adrian Dușa :

> On Tue, Oct 6, 2015 at 3:06 AM, Simon Urbanek  >
> wrote:
>
> >
> > [...]
> >
> > To clarify, legally, you can fork a standard GPL package and make any
> > changes you want, including changing authors fields etc. If you don't own
> > copyright for the entire work then you cannot change the license without
> > consent from the other copyright holders, otherwise you have all the
> rights
> > as anyone else granted by the license.
> >
> > However, CRAN policies go beyond that and say
> >
> > "Where code is copied (or derived) from the work of others (including
> from
> > R itself), care must be taken that any copyright/license statements are
> > preserved and authorship is not misrepresented.
> > Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the
> authors
> > of such code. Alternatively, the ‘Author’ field should list these authors
> > as contributors.
> > Where copyrights are held by an entity other than the package authors,
> > this should preferably be indicated via ‘cph’ roles in the ‘Authors@R’
> > field, or using a ‘Copyright’ field (if necessary referring to an
> > inst/COPYRIGHTS file)."
> >
> > This means that CRAN will not accept a package where you did not list all
> > copyright holders in one of the Author roles, although it is legal for
> you
> > to do so outside of CRAN.
> >
>
>
> Please pardon my delay, I am writing from California and it's still morning
> here.
> I understand very well that I need to keep the previous co-author in the
> list of authors, and duly acknowledge his contribution.
> I would still be interested in the formal rules of compiling the citation
> file (example package Rcmdr), but for the moment it can be automatically
> generated via citation("QCA").
>
> Both of these are perfectly compliant with the CRAN policies.
>
> As another attempt to solve the matter, I wonder if any rules would be
> broken if I used the .onAttach(...) function to print a message in the line
> of:
>
> > library(QCA)
>
> Users are encouraged to cite this package as:
>
>   Dusa, Adrian (2015). QCA: Qualitative Comparative Analysis. R Package
> Version 1.2-0,
>   URL: http://cran.r-project.org/package=QCA
>
> This is just an encouragement, not a requirement, and the official citation
> file meets the CRAN policies. Would that be acceptable?
>
> Best wishes,
> Adrian
>
>
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr.90
> 050663 Bucharest sector 5
> Romania
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Circular dependencies and vignette building

[Dan Tenenbaum]

Yes, please upload PCHiCdata to the same issue as Chicago, do not start a new 
issue.
Thanks,
Dan


- Original Message -
> From: "Hervé Pagès" 
> To: "Jonathan Cairns" , 
> bioc-devel@r-project.org
> Cc: "Mikhail Spivakov" , "Paula 
> Freire-Pritchett"
> 
> Sent: Tuesday, October 6, 2015 11:25:05 AM
> Subject: Re: [Bioc-devel] Circular dependencies and vignette building
> 
> Hi Jonathan,
> 
> This is indeed a very common situation and you are doing the right
> thing. Please upload PCHiCdata to our issue tracker in the same issue
> as Chicago. We'll make sure that the build system installs the 2
> packages (Chicago and PCHiCdata, in that order) before it tries to
> build Chicago.
> 
> Thanks,
> H.
> 
> On 10/06/2015 09:55 AM, Jonathan Cairns wrote:
> > Hi,
> >
> > I am attempting to submit a software package "Chicago", and a
> > corresponding data package "PCHiCdata", to Bioconductor. However,
> > I have an issue with circular dependencies.
> >
> > Chicago "suggests" PCHiCdata, because one of the data sets in
> > PCHiCdata is used to build the vignette. As a result, when BioC
> > attempts to R CMD BUILD Chicago, it cannot build the vignette and
> > thus returns an error. However, PCHiCdata "depends" on Chicago,
> > because the data use a class from Chicago, so I can't build and
> > install it first. (I got around this issue on my local machine by
> > installing Chicago before building the vignette.)
> >
> > One issue is that we found it impossible to create a data set that
> > was small enough to fit in the software package, but large enough
> > to have enough information to run the full Chicago workflow on.
> > This is why the vignette depends on the external data package.
> >
> > I imagined this situation would be common, but I couldn't find any
> > advice on it. Is there a sensible/recommended way to resolve this
> > dependency?
> >
> > Thanks,
> >
> > Jonathan
> >
> > The Babraham Institute, Babraham Research Campus, Cambridge CB22
> > 3AT Registered Charity No. 1053902.
> > The information transmitted in this email is directed only to the
> > addressee. If you received this in error, please contact the
> > sender and delete this email from your system. The contents of
> > this e-mail are the views of the sender and do not necessarily
> > represent the views of the Babraham Institute. Full conditions at:
> > www.babraham.ac.uk
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> 
> --
> Hervé Pagès
> 
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
> 
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] authorship and citation

[Gabriel Becker]

Adrian,

I am not on the CRAN  or R-core teams, so the following is my own view,
but...

> library(QCA)
>
> Users are encouraged to cite this package as:
>
>   Dusa, Adrian (2015). QCA: Qualitative Comparative Analysis. R Package
> Version 1.2-0,
>   URL: http://cran.r-project.org/package=QCA
>
> This is just an encouragement, not a requirement, and the official citation
> file meets the CRAN policies. Would that be acceptable?
>


At the very least, this is seems to be a flagrant violation of the *spirit*
of the CRAN policy, which AFAIK is intended to enforce acknowledgement of
the contributions of all copyright holders in the package. The fact that
you are trying to bypass the policy by suggesting users use an unofficial
citation which would not comply with the policy while maintaining an
official one which complies, but which you don't want users to see  is
probably a suggestion that you shouldn't do that.

Best,
~G


>
> Best wishes,
> Adrian
>
>
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr.90
> 050663 Bucharest sector 5
> Romania
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Gabriel Becker]

Adrian,

Responses inline

On Tue, Oct 6, 2015 at 1:58 PM, Adrian Dușa  wrote:

> Hi Gabriel,
>
> On Tue, Oct 6, 2015 at 10:59 PM, Gabriel Becker 
> wrote:
>
>> [...]
>>
>> At the very least, this is seems to be a flagrant violation of the
>> *spirit* of the CRAN policy, which AFAIK is intended to enforce
>> acknowledgement of the contributions of all copyright holders in the
>> package. The fact that you are trying to bypass the policy by suggesting
>> users use an unofficial citation which would not comply with the policy
>> while maintaining an official one which complies, but which you don't want
>> users to see  is probably a suggestion that you shouldn't do that.
>>
>
>
> But that is the very point: I read the CRAN policies twice, and there is
> no official guideline on how to compile the citation.
> Regarding the Source packages, the policies mention:
>

> ##
> The ownership of copyright and intellectual property rights of all
> components of the package must be clear and unambiguous (including from the
> authors specification in the DESCRIPTION file). Where code is copied (or
> derived) from the work of others (including from R itself), care must be
> taken that any copyright/license statements are preserved and authorship is
> not misrepresented.
> Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the authors
> of such code. Alternatively, the ‘Author’ field should list these authors
> as contributors.
>
> Where copyrights are held by an entity other than the package authors,
> this should preferably be indicated via ‘cph’ roles in the ‘Authors@R’
> field, or using a ‘Copyright’ field (if necessary referring to an
> inst/COPYRIGHTS file).
>
> Trademarks must be respected.
> ##
>
> Now, that requirement is already met: the former author is still in the
> authors' list. So the contribution of the former author is duly
> acknowledged, but the fundamental issue of my question related to the
> citation file, for which the CRAN policies doesn't offer any other
> information.
>

The citation mechanism, AFAIK, has two purposes. One is to associate a
published article/book/etc with an r package, where appropriate (and there
authorship and inclusion would need to meet the requirements of the
publishing journal). The other is to give a way for other works to cite the
work done in developing the package.

If you don't acknowledge that it is "heavily implied" that in the second
case all authors of the package should appear in the citation (this is
almost definitionally true of citations, I would think) I'm not really sure
what to tell you.

Approached from a different angle, what reason do you have for wanting the
other other to not appear in the citation for the package other than
minimizing/not acknowledging the copyright-holding work that he or she did
on the project?


>
> If the spirit of the CRAN policies is to enforce citing each and every one
> of the authors, then I don't understand why the citation from package Rcmdr
> meets this spirit, while my suggestion doesn't.
>

I don't have any knowledge of what Rcmdr does with regards to the citations
or the historical context that would make it relevant to the discussion
here.

>
> I apologize for pushing this topic to the limit, but I haven't got an
> answer to this question yet...
>

With respect, not receiving the answer you wanted isn't the same as not
receiving an answer.

Best,
~G


>
> Best wishes,
> Adrian
>
> PS: @Thierry: I did take a look at RODBC, but the citation information is
> generated automatically upon package installation (no other special file on
> CRAN)
>
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr.90
> 050663 Bucharest sector 5
> Romania
>



-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Gabriel Becker]

On Tue, Oct 6, 2015 at 2:52 PM, Adrian Dușa  wrote:

> Dear Gabriel,
>
> On Wed, Oct 7, 2015 at 12:39 AM, Gabriel Becker 
> wrote:
>
>> [...]
>>
>>>
>>> I apologize for pushing this topic to the limit, but I haven't got an
>>> answer to this question yet...
>>>
>>
>> With respect, not receiving the answer you wanted isn't the same as not
>> receiving an answer.
>>
>
> I very much appreciate your patience with me, and I am grateful for it.
> The question is I believe very important, for I would like to avoid
> submitting a new version of the package only to be told that I did
> something wrong.
>
> As so many other packages seem to have a lot of flexibility in compiling
> the citation file, what I am inquiring is: will I be prosecuted for
> submitting a new version which doesn't include all the authors in the
> citation file, especially since the other author is no longer contributing?
> (let's say I will provide a single author, published journal article,
> referring specifically to this package).
>

I am not part of CRAN, as I prefaced my initial response with, so I can't
speak to "prosecution". You will have to wait for them to respond (again)
for a definitive answer to that. I do think, however, that if you did this
specifically to disenfranchise your previous collaborator you would be
morally in the wrong, and substantially so.



>
> The work of the other author is duly acknowledged in his position in the
> authors' list.
> As I previously wrote, citing Dusa and Other (2015) implies equal citation
> rights for unequal work, a thing that I am uncomfortable with. There is a
> huge amount of work being involved in this subsequent version, to which the
> former author didn't contribute anything at all...
>

It really doesn't imply this at all, at least to me (and I don't think I'm
alone here).  In most authorship-listing schemes first author is the one
who did the most direct work (wrote the draft, in the case of an article).
On the other hand, citing Dusa (2015) implies NO work by Other in the
entity being cited. That is clearly and concretely not the case.

I will leave you with this, which may sound like a personal attack but I
assure you it is not: I myself would not consider collaborating with you on
a project given your apparent attitude towards the contributions of people
no longer actively working on projects you own.

Best,
~G


>
> Best wishes,
> Adrian
>
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr.90
> 050663 Bucharest sector 5
> Romania
>



-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Adrian Dușa]

Hi Gabriel,

On Tue, Oct 6, 2015 at 10:59 PM, Gabriel Becker 
wrote:

> [...]
>
> At the very least, this is seems to be a flagrant violation of the
> *spirit* of the CRAN policy, which AFAIK is intended to enforce
> acknowledgement of the contributions of all copyright holders in the
> package. The fact that you are trying to bypass the policy by suggesting
> users use an unofficial citation which would not comply with the policy
> while maintaining an official one which complies, but which you don't want
> users to see  is probably a suggestion that you shouldn't do that.
>


But that is the very point: I read the CRAN policies twice, and there is no
official guideline on how to compile the citation.
Regarding the Source packages, the policies mention:

##
The ownership of copyright and intellectual property rights of all
components of the package must be clear and unambiguous (including from the
authors specification in the DESCRIPTION file). Where code is copied (or
derived) from the work of others (including from R itself), care must be
taken that any copyright/license statements are preserved and authorship is
not misrepresented.
Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the authors
of such code. Alternatively, the ‘Author’ field should list these authors
as contributors.

Where copyrights are held by an entity other than the package authors, this
should preferably be indicated via ‘cph’ roles in the ‘Authors@R’ field, or
using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS
file).

Trademarks must be respected.
##

Now, that requirement is already met: the former author is still in the
authors' list. So the contribution of the former author is duly
acknowledged, but the fundamental issue of my question related to the
citation file, for which the CRAN policies doesn't offer any other
information.

If the spirit of the CRAN policies is to enforce citing each and every one
of the authors, then I don't understand why the citation from package Rcmdr
meets this spirit, while my suggestion doesn't.

I apologize for pushing this topic to the limit, but I haven't got an
answer to this question yet...

Best wishes,
Adrian

PS: @Thierry: I did take a look at RODBC, but the citation information is
generated automatically upon package installation (no other special file on
CRAN)

-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Adrian Dușa]

On Tue, Oct 6, 2015 at 11:58 PM, Adrian Dușa  wrote:
>
> [...]
> If the spirit of the CRAN policies is to enforce citing each and every
one of the authors, then I don't understand why the citation from package
Rcmdr meets this spirit, while my suggestion doesn't.
>
> I apologize for pushing this topic to the limit, but I haven't got an
answer to this question yet...


Out of curiosity, upon random checks there seem to be many other packages
in similar situations (which have multiple authors, but cite only a subset):
SamplingStrata
sandwich
SAVE
seawave

What all of these cases seem to have in common is an older published
journal article, and the citation adhered to that article irrespective of
how many authors subsequently contributed to that package.

Would it suffice to provide such an article, then?
Adrian

--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Adrian Dușa]

Dear Gabriel,

On Wed, Oct 7, 2015 at 12:39 AM, Gabriel Becker 
wrote:

> [...]
>
>>
>> I apologize for pushing this topic to the limit, but I haven't got an
>> answer to this question yet...
>>
>
> With respect, not receiving the answer you wanted isn't the same as not
> receiving an answer.
>

I very much appreciate your patience with me, and I am grateful for it.
The question is I believe very important, for I would like to avoid
submitting a new version of the package only to be told that I did
something wrong.

As so many other packages seem to have a lot of flexibility in compiling
the citation file, what I am inquiring is: will I be prosecuted for
submitting a new version which doesn't include all the authors in the
citation file, especially since the other author is no longer contributing?
(let's say I will provide a single author, published journal article,
referring specifically to this package).

The work of the other author is duly acknowledged in his position in the
authors' list.
As I previously wrote, citing Dusa and Other (2015) implies equal citation
rights for unequal work, a thing that I am uncomfortable with. There is a
huge amount of work being involved in this subsequent version, to which the
former author didn't contribute anything at all...

Best wishes,
Adrian

-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[R-pkg-devel] src/install.libs.R

[Facundo Muñoz]

Dear all,

I need to make use of the |src/install.libs.R| file, in order to perform
certain tasks at installation time.
I followed the R-exts doc
.
However, R CMD INSTALL seems to never run the script.

Here is a minimal reproducible example.
It makes use of |devtools| to simplify the example, but I have tried the
installation manually as well.

|## Create a minimal buildable package library(devtools)
create('testpkg') ## Write src/install.libs.R dir.create('testpkg/src')
test.file <- path.expand('~/testfile.txt') diag.lines <- c(
deparse(quote(stop('This should break the installation'))),
deparse(quote(file.create(test.file))) ) writeLines(diag.lines,
'testpkg/src/install.libs.R') ## Install package ## also tried manually
with R CMD INSTALL install('testpkg') ## The installation did not break
## nor the file has been created file.exists('~/testfile.txt') # FALSE
## Cleanup remove.packages('testpkg') unlink('testpkg', recursive = TRUE) |

Am I missing something?

thanks in advance
ƒacu.-

PS: by the way…

|> sessionInfo() R version 3.2.2 (2015-08-14) Platform:
x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.2 LTS locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES=en_US.UTF-8 LC_PAPER=fr_FR.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
LC_TELEPHONE=C LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C attached
base packages: [1] stats graphics grDevices utils datasets methods base
other attached packages: [1] devtools_1.8.0.9000 loaded via a namespace
(and not attached): [1] tools_3.2.2 memoise_0.2.1 digest_0.6.8 |

​

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] authorship and citation

[Adrian Dușa]

On Wed, Oct 7, 2015 at 1:07 AM, Gabriel Becker  wrote:

>
> [...]
>
>>
>> The work of the other author is duly acknowledged in his position in the
>> authors' list.
>> As I previously wrote, citing Dusa and Other (2015) implies equal
>> citation rights for unequal work, a thing that I am uncomfortable with.
>> There is a huge amount of work being involved in this subsequent version,
>> to which the former author didn't contribute anything at all...
>>
>
> It really doesn't imply this at all, at least to me (and I don't think I'm
> alone here).  In most authorship-listing schemes first author is the one
> who did the most direct work (wrote the draft, in the case of an article).
> On the other hand, citing Dusa (2015) implies NO work by Other in the
> entity being cited. That is clearly and concretely not the case.
>

That is another way of looking at things, but I don't necessarily agree
with you. It doesn't imply NO work, since that is duly recognised by the
presence of the Other in the authors' list.
And I have nevertheless changed my suggestion from Dusa (2015) with a
citation of a previous (older, 2007) article, one that laid the very
foundations for the package, and an article that the Other had also no
contribution at all.

Given that many other packages seem to have the liberty to do so, the
question is under what conditions do I have this liberty as well.

Best wishes,
Adrian


-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Prof Brian Ripley]

On 06/10/2015 12:58, S Ellison wrote:

(quoting without attribution to the author, who would appear to be Uwe 
Liggges).



The former co-author contributed, so he is still author and probably copyright
holder and has to be listed among the authors, otherwise it would be a CRAN
policy violation ...


It's a bit of a philosophical question right now, but at some point in a 
developing package's life - particularly one that starts small but is 
subsequently refactored in growth - there may be no code left that was 
contributed by the original developer.

Is there a point at which the original developer should not stay on the author 
list?


Authorship is not just about code.  For example, there are functions in 
R which have been completely recoded, but the design and documentation 
remain.  Copyright can apply to designs and there is shading between 
inspiration and infringement.   And many of us believe that inspiration 
should be credited as a moral even if not a legal obligation.


As in "George Washington's axe" and similar myths, if all the parts are 
replaced it remains of the original design.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Dirk Eddelbuettel]

On 6 October 2015 at 13:38, Prof Brian Ripley wrote:
| Authorship is not just about code.

An fair credit about is the only currency we have in Open Source projects.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

[Joris Meys]

Thank you for looking at the issue. I've tried it with a tiny package
myself and I get the same results. So the problem should solve itself in
time.
Also thank you Michael for explaining the difference in behaviour when
debugging.

Cheers
Joris

On Tue, Oct 6, 2015 at 2:41 AM, Duncan Murdoch 
wrote:

> On 05/10/2015 8:25 PM, Matt Dowle wrote:
> >
> > On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch  > > wrote:
> >
> > On 05/10/2015 7:24 PM, Matt Dowle wrote:
> > > Joris Meys  gmail.com > writes:
> > >
> > >>
> > >> Hi all,
> > >>
> > >> I have a puzzling problem related to nchar. In R 3.2.1, the
> internal
> > > nchar
> > >> gained an extra argument (see
> > >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
> > >>
> > >> I've been testing code using the package copula, and at home I'm
> > still
> > >> running R 3.2.0 (I know, I know...). When trying the following
> > code, I
> > > got
> > >> an error:
> > >>
> > >>> library(copula)
> > >>> fgmCopula(0.8)
> > >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
> > >>   4 arguments passed to .Internal(nchar) which requires 3
> > >>
> > >> Cheers
> > >> Joris
> > >
> > >
> > > I'm seeing a similar problem. IIUC, the Windows binary .zip from
> > CRAN of
> > > any package using base::nchar is affected. Could someone check my
> > answer
> > > here is correct please :
> http://stackoverflow.com/a/32959306/403310
> >
> > Nobody has posted a simple reproducible example here, so it's kind of
> > hard to say.
> >
> > I would have guessed that a change to the internal signature of the C
> > code underlying nchar() wouldn't have any effect on a package that
> > called the R nchar() function.
> >
> > When I put together my own example (a tiny package containing a
> function
> > calling nchar(), built to .zip using R 3.2.2, installed into R
> 3.2.0),
> > it confirmed my guess.
> >
> > On the other hand, if some package is calling the .Internal function
> > directly, I'd expect that to break.  Packages shouldn't do that.
> >
> > So I'd say there's been no evidence posted of a problem in R here,
> > though there may be problems in some of the packages involved.  I'd
> > welcome an example that provided some usable evidence.
> >
> > Duncan Murdoch
> >
> >
> > I don't have Windows so am not able to test unfortunately.
> > data.table makes no calls to .Internal(). Such calls are caught and
> > prevented by R CMD check.
> > Both data.table and copula contain "ByteCompile: yes" in their
> > DESCRIPTION files.  Does the toy package break with that setting?
> > Matt
> >
>
> That's it.  With "ByteCompile: yes" I get the same error.
>
> I don't know if there's anything we can do about this now, but we should
> be able to avoid it in the future.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

[Joris Meys]

On Tue, Oct 6, 2015 at 1:57 AM, Duncan Murdoch 
wrote:

> On 05/10/2015 7:24 PM, Matt Dowle wrote:
> > Joris Meys  gmail.com> writes:
> >
> >>
> >> Hi all,
> >>
> >> I have a puzzling problem related to nchar. In R 3.2.1, the internal
> > nchar
> >> gained an extra argument (see
> >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
> >>
> >> I've been testing code using the package copula, and at home I'm still
> >> running R 3.2.0 (I know, I know...). When trying the following code, I
> > got
> >> an error:
> >>
> >>> library(copula)
> >>> fgmCopula(0.8)
> >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
> >>   4 arguments passed to .Internal(nchar) which requires 3
> >>
> >> Cheers
> >> Joris
> >
> >
> > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN of
> > any package using base::nchar is affected. Could someone check my answer
> > here is correct please : http://stackoverflow.com/a/32959306/403310
>
> Nobody has posted a simple reproducible example here, so it's kind of
> hard to say.
>

You're free to try the simple reproducible example I've provided in my
original question. Tried that out on 3 different computers, and I got the
same behaviour 3 times.


>
> I would have guessed that a change to the internal signature of the C
> code underlying nchar() wouldn't have any effect on a package that
> called the R nchar() function.
>
> When I put together my own example (a tiny package containing a function
> calling nchar(), built to .zip using R 3.2.2, installed into R 3.2.0),
> it confirmed my guess.
>
> On the other hand, if some package is calling the .Internal function
> directly, I'd expect that to break.  Packages shouldn't do that.
>

I never said the package called the internal function, because it doesn't.
The error message reports there's an error in substr(sc[i], 2, nchar(sc[i])
- 1). Then it continues to indicate the problem occurs at the moment
nchar() calles the internal function. That's how the core team wrote the
nchar() function.


> So I'd say there's been no evidence posted of a problem in R here,
> though there may be problems in some of the packages involved.  I'd
> welcome an example that provided some usable evidence.
>

With all due respect for your involvement in and knowledge about R, I have
the impression you read too quickly through the mail. There is a problem
and it is reproducible. I'm just not smart enough to figure out how the
problem came about.

Kind regards
Joris


>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Simon Urbanek]

On Oct 6, 2015, at 7:58 AM, S Ellison  wrote:

>> The former co-author contributed, so he is still author and probably 
>> copyright
>> holder and has to be listed among the authors, otherwise it would be a CRAN
>> policy violation ...
> 
> It's a bit of a philosophical question right now, but at some point in a 
> developing package's life - particularly one that starts small but is 
> subsequently refactored in growth - there may be no code left that was 
> contributed by the original developer.
> 
> Is there a point at which the original developer should not stay on the 
> author list?
> 

CRAN policies only require the presence of copyright holders, so if there is no 
content left to which the original author has copyright, then s/he doesn't need 
to be listed. Note that this extends to all the content, not just code.

Cheers,
S


> S Ellison
> 
> 
> 
> ***
> This email and any attachments are confidential. Any u...{{dropped:14}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[S Ellison]

> The former co-author contributed, so he is still author and probably copyright
> holder and has to be listed among the authors, otherwise it would be a CRAN
> policy violation ...

It's a bit of a philosophical question right now, but at some point in a 
developing package's life - particularly one that starts small but is 
subsequently refactored in growth - there may be no code left that was 
contributed by the original developer.

Is there a point at which the original developer should not stay on the author 
list?

S Ellison



***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If 
you have received this message in error, please notify the sender 
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com 
and delete this message and any copies from your computer and network. 
LGC Limited. Registered in England 2991879. 
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Martyn Plummer]

On 06 Oct 2015, at 14:09, S Ellison  wrote:

>> The former co-author contributed, so he is still author and probably 
>> copyright
>> holder and has to be listed among the authors, otherwise it would be a CRAN
>> policy violation ...
> 
> It's a bit of a philosophical question right now, but at some point in a 
> developing package's life - particularly one that starts small but is 
> subsequently refactored in growth - there may be no code left that was 
> contributed by the original developer.

That is indeed the philosophical question of the ship of Theseus.

Martyn

> Is there a point at which the original developer should not stay on the 
> author list?
> 
> S Ellison
> 
> 
> 
> ***
> This email and any attachments are confidential. Any u...{{dropped:19}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

[Duncan Murdoch]

On 06/10/2015 8:48 AM, Joris Meys wrote:
> 
> 
> On Tue, Oct 6, 2015 at 1:57 AM, Duncan Murdoch  > wrote:
> 
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
> > Joris Meys  gmail.com > writes:
> >
> >>
> >> Hi all,
> >>
> >> I have a puzzling problem related to nchar. In R 3.2.1, the internal
> > nchar
> >> gained an extra argument (see
> >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
> >>
> >> I've been testing code using the package copula, and at home I'm still
> >> running R 3.2.0 (I know, I know...). When trying the following code, I
> > got
> >> an error:
> >>
> >>> library(copula)
> >>> fgmCopula(0.8)
> >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
> >>   4 arguments passed to .Internal(nchar) which requires 3
> >>
> >> Cheers
> >> Joris
> >
> >
> > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN of
> > any package using base::nchar is affected. Could someone check my answer
> > here is correct please : http://stackoverflow.com/a/32959306/403310
> 
> Nobody has posted a simple reproducible example here, so it's kind of
> hard to say.
> 
> 
> You're free to try the simple reproducible example I've provided in my
> original question. Tried that out on 3 different computers, and I got
> the same behaviour 3 times.

As I posted yesterday, with Matt's help I was able to find a simple
reproduction of the bug.

The reason I wouldn't count your original post as a simple reproducible
example (and the same applies to what I saw on Stack Overflow), was that
it required a fairly large package (copula) in the demonstration.  I'm
not familiar with the internals of that package (or Matt's package
discussed on Stack Overflow), so it would be a lot of work for me to
identify what it was in them that triggered the bug.  If the bug had
required those packages and couldn't be demonstrated without them, then
it would likely be a bug in those packages, not in R.


>  
> 
> 
> I would have guessed that a change to the internal signature of the C
> code underlying nchar() wouldn't have any effect on a package that
> called the R nchar() function.
> 
> When I put together my own example (a tiny package containing a function
> calling nchar(), built to .zip using R 3.2.2, installed into R 3.2.0),
> it confirmed my guess.
> 
> On the other hand, if some package is calling the .Internal function
> directly, I'd expect that to break.  Packages shouldn't do that.
> 
> 
> I never said the package called the internal function, because it
> doesn't. The error message reports there's an error insubstr(sc[i], 2,
> nchar(sc[i]) - 1). Then it continues to indicate the problem occurs at
> the moment nchar() calles the internal function. That's how the core
> team wrote the nchar() function.
> 
> 
> So I'd say there's been no evidence posted of a problem in R here,
> though there may be problems in some of the packages involved.  I'd
> welcome an example that provided some usable evidence.
> 
> 
> With all due respect for your involvement in and knowledge about R, I
> have the impression you read too quickly through the mail. There is a
> problem and it is reproducible. I'm just not smart enough to figure out
> how the problem came about.
> 

I sometimes do read too quickly and miss important details, but I don't
think I did in this case.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

[Joris Meys]

On Tue, Oct 6, 2015 at 3:02 PM, Duncan Murdoch 
wrote:

> On 06/10/2015 8:48 AM, Joris Meys wrote:
>
>
> The reason I wouldn't count your original post as a simple reproducible
> example (and the same applies to what I saw on Stack Overflow), was that
> it required a fairly large package (copula) in the demonstration.  I'm
> not familiar with the internals of that package (or Matt's package
> discussed on Stack Overflow), so it would be a lot of work for me to
> identify what it was in them that triggered the bug.  If the bug had
> required those packages and couldn't be demonstrated without them, then
> it would likely be a bug in those packages, not in R.
>

Dear Duncan,

thank you for the help and the extra clarification. I'll keep it in mind
for the future.
Cheers
Joris

-- 
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Bioc-devel] Circular dependencies and vignette building

[Jonathan Cairns]

Hi,

I am attempting to submit a software package "Chicago", and a corresponding 
data package "PCHiCdata", to Bioconductor. However, I have an issue with 
circular dependencies.

Chicago "suggests" PCHiCdata, because one of the data sets in PCHiCdata is used 
to build the vignette. As a result, when BioC attempts to R CMD BUILD Chicago, 
it cannot build the vignette and thus returns an error. However, PCHiCdata 
"depends" on Chicago, because the data use a class from Chicago, so I can't 
build and install it first. (I got around this issue on my local machine by 
installing Chicago before building the vignette.)

One issue is that we found it impossible to create a data set that was small 
enough to fit in the software package, but large enough to have enough 
information to run the full Chicago workflow on. This is why the vignette 
depends on the external data package.

I imagined this situation would be common, but I couldn't find any advice on 
it. Is there a sensible/recommended way to resolve this dependency?

Thanks,

Jonathan

The Babraham Institute, Babraham Research Campus, Cambridge CB22 3AT Registered 
Charity No. 1053902.
The information transmitted in this email is directed only to the addressee. If 
you received this in error, please contact the sender and delete this email 
from your system. The contents of this e-mail are the views of the sender and 
do not necessarily represent the views of the Babraham Institute. Full 
conditions at: www.babraham.ac.uk
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] authorship and citation

[Adrian Dușa]

On Tue, Oct 6, 2015 at 3:06 AM, Simon Urbanek 
wrote:

>
> [...]
>
> To clarify, legally, you can fork a standard GPL package and make any
> changes you want, including changing authors fields etc. If you don't own
> copyright for the entire work then you cannot change the license without
> consent from the other copyright holders, otherwise you have all the rights
> as anyone else granted by the license.
>
> However, CRAN policies go beyond that and say
>
> "Where code is copied (or derived) from the work of others (including from
> R itself), care must be taken that any copyright/license statements are
> preserved and authorship is not misrepresented.
> Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the authors
> of such code. Alternatively, the ‘Author’ field should list these authors
> as contributors.
> Where copyrights are held by an entity other than the package authors,
> this should preferably be indicated via ‘cph’ roles in the ‘Authors@R’
> field, or using a ‘Copyright’ field (if necessary referring to an
> inst/COPYRIGHTS file)."
>
> This means that CRAN will not accept a package where you did not list all
> copyright holders in one of the Author roles, although it is legal for you
> to do so outside of CRAN.
>


Please pardon my delay, I am writing from California and it's still morning
here.
I understand very well that I need to keep the previous co-author in the
list of authors, and duly acknowledge his contribution.
I would still be interested in the formal rules of compiling the citation
file (example package Rcmdr), but for the moment it can be automatically
generated via citation("QCA").

Both of these are perfectly compliant with the CRAN policies.

As another attempt to solve the matter, I wonder if any rules would be
broken if I used the .onAttach(...) function to print a message in the line
of:

> library(QCA)

Users are encouraged to cite this package as:

  Dusa, Adrian (2015). QCA: Qualitative Comparative Analysis. R Package
Version 1.2-0,
  URL: http://cran.r-project.org/package=QCA

This is just an encouragement, not a requirement, and the official citation
file meets the CRAN policies. Would that be acceptable?

Best wishes,
Adrian


-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr.90
050663 Bucharest sector 5
Romania

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel