Re: [Rd] cyclic namespace dependency detected when loading ...
On 21.08.2013 16:34, Jannis wrote: Hi R users, I am developing two packages. Each package uses some functions from the other package. Now when I define these dependencies in the NAMESPACE file (via importFrom(,function1,)), i get this error (when building one package): cyclic namespace dependency detected when loading 'XX', already loading ‘YYY’, ‘X’ Is there any way to prevent this error? Shouldn't this case be allowed in some way? Or can package dependencies only be in one direction? Imports only in one direction: Package A has to be installed before package B and package B before package A now. The hen and the egg... Best, Uwe Ligges Thanks Jannis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Correct NAMESPACE approach when writing an S3 method for a generic in another package
What I do, which is probably wrong, but at least it works, is export the s3 method as a function. i.e. instead of S3method(genericfunction, myclass) I do export(genericfunction.myclass) Hadley On Fri, Aug 23, 2013 at 11:01 PM, Gavin Simpson wrote: > Dear List, > > In one of my packages I have an S3 method for the plot3d generic > function from package rgl. I am trying to streamline my Depends > entries but don't know how to have > > plot3d(foo) > > in the examples section for the plot3d method in my package, without > rgl being in Depends. > > Note that I importFrom(rgl, plotd3d) and register my S3 method via > S3Method() in the NAMESPACE. > > If rgl is not in Depends but in Imports, I see this when checking the package > >> ## 3D plot of data with curve superimposed >> plot3d(aber.pc, abernethy2) > Error: could not find function "plot3d" > > I presume this is because rgl's namespace is only loaded but the > package is not attached to the search path. > > Writing R extensions indicates that one can export from a namespace > something that was imported from another package namespace. I thought > that might help the situation, and now the code doesn't raise an > error, I get > > * checking for missing documentation entries ... WARNING > Undocumented code objects: > ‘plot3d’ > All user-level objects in a package should have documentation entries. > See the chapter ‘Writing R documentation files’ in the ‘Writing R > Extensions’ manual. > > as I don't document plot3d() itself. > > What is the recommended combination of Depends and Imports plus > NAMESPACE directives etc that one should use in this situation? Or am > I missing something else? > > I have a similar issue with my package including an S3 method for a > generic in the lattice package, so if possible I could get rid of both > of these from Depends if I can solve the above issue. > > Thanks in advance. > > Gavin > > -- > Gavin Simpson > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Correct NAMESPACE approach when writing an S3 method for a generic in another package
The combination of importFrom(, ) S3method(, , ) works fine for me in a toy example. I don't have OpenGL on my laptop to test your actual case but I see no reason it wouldn't work. ~G On Sun, Aug 25, 2013 at 7:29 AM, Hadley Wickham wrote: > What I do, which is probably wrong, but at least it works, is export > the s3 method as a function. i.e. instead of > > S3method(genericfunction, myclass) > > I do > > export(genericfunction.myclass) > > Hadley > > On Fri, Aug 23, 2013 at 11:01 PM, Gavin Simpson wrote: > > Dear List, > > > > In one of my packages I have an S3 method for the plot3d generic > > function from package rgl. I am trying to streamline my Depends > > entries but don't know how to have > > > > plot3d(foo) > > > > in the examples section for the plot3d method in my package, without > > rgl being in Depends. > > > > Note that I importFrom(rgl, plotd3d) and register my S3 method via > > S3Method() in the NAMESPACE. > > > > If rgl is not in Depends but in Imports, I see this when checking the > package > > > >> ## 3D plot of data with curve superimposed > >> plot3d(aber.pc, abernethy2) > > Error: could not find function "plot3d" > > > > I presume this is because rgl's namespace is only loaded but the > > package is not attached to the search path. > > > > Writing R extensions indicates that one can export from a namespace > > something that was imported from another package namespace. I thought > > that might help the situation, and now the code doesn't raise an > > error, I get > > > > * checking for missing documentation entries ... WARNING > > Undocumented code objects: > > plot3d > > All user-level objects in a package should have documentation entries. > > See the chapter Writing R documentation files in the Writing R > > Extensions manual. > > > > as I don't document plot3d() itself. > > > > What is the recommended combination of Depends and Imports plus > > NAMESPACE directives etc that one should use in this situation? Or am > > I missing something else? > > > > I have a similar issue with my package including an S3 method for a > > generic in the lattice package, so if possible I could get rid of both > > of these from Depends if I can solve the above issue. > > > > Thanks in advance. > > > > Gavin > > > > -- > > Gavin Simpson > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Chief Scientist, RStudio > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 13-08-22 11:54 PM, Yihui Xie wrote:
Maybe it is not a good idea for R CMD check to check ::: at all, and a
warning in R-exts and ?':::' may well be enough. On the other hand, it
is just so easy to get around :::, because everybody can see its
source code:
It's a really bad idea to write tricky code to subvert the tests. If
the tests are wrong, you can argue for changes (and in this case you
did, and changes were made), but if you can't give a convincing
argument, you should follow the good practices that the repository
policies enforce.
Duncan Murdoch
`:::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
Then the package authors who really want to take the risk may start
another "hide and seek" game, e.g.
`%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
inherits = FALSE)
'stats' %:::% 'Pillai'
Non-exported functions do not necessarily imply instability. Maybe it
is just because the author is too lazy to document them, or he/she did
not realize these functions happen to be useful for another author.
Although R-devel does not warn against ::: on the packages of the same
maintainer now, these maintainers may change in the future, or one
maintainer can be an author but not maintainer of another package,
from which he/she imports an unexported function, or package authors
have coordinated well with each other about the unexported functions.
I believe there are other legitimate reasons for :::, which might make
it difficult for R to cover all these cases, and also bring additional
communications between package authors and CRAN.
In conclusion, R CMD check cannot really stop :::, and ::: can be
there for good reasons, so how about just let it go?
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Thu, Aug 22, 2013 at 9:02 PM, Gabriel Becker wrote:
Hey guys,
Because I was curious and had nothing else that I should have been doing
(that second part is a lie), I looked into the namespace code.
I have a working patch that implements importHiddenFrom. It doesn't
currently check whether you then export that symbol (which should not be
allowed) but that would be easy to implement.
Is there any desire from R-core to have add the importHiddenFrom
functionality? If so I can add the export check and submit the patch either
here or on bugzilla. I figure its a long shot but hey, at least I now know
how the namespace stuff works.
I do agree with Peter Meilstrup that poking around at the internals of
someone else's code is often not a good idea, but as others have pointed
out it is done in practice in some fairly high-profile packages, and if its
going to happen it seems like it would be nice to indicate as much in the
NAMESPACE file.
~G
On Thu, Aug 22, 2013 at 5:41 PM, Gray wrote:
Peter Meilstrup: (05:01PM on Thu, Aug 22)
One most often encounters namespace conflicts at the user level, when
loading two packages that have no logical connection other than both
bearing on your problem of the moment.
Unless I'm mistaken, you can reassign the hidden functions, ie
fna <- joespackage:::usefulfunction
fnb <- janespackage:::usefulfunction
which is a little bit of a pain, but makes the user's code
unambiguous. This also works with two colons for explicitly exported
functions.
--
Gray Calhoun, Assistant Professor of Economics at Iowa State
http://gray.clhn.co (web)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On 13-08-24 12:46 PM, Kasper Daniel Hansen wrote: On Thu, Aug 22, 2013 at 8:27 PM, Peter Meilstrup Using ::: on a package you don't control can be more dangerous. For a package author to choose to export a function to the public interface represents at least some assurance that that interface will be stable or slow-moving. But there are no implied assurances about how code in the private namespace might change behind the scenes. I might completely refactor the code and change the behavior of any private function between 0.0.1 releases, but I would not do that for exported functions. This is true (that it could be dangerous), but sometimes, as a package author, I am willing to take this risk. Personally, I don't do this lightly, but sometimes there is no way around it, particular if the hidden function does some magic in its own NAMESPACE. It is not all functions that one can just easily copy over into you own package. It is fine to say that the use of ::: should be discouraged, it is another thing if it prevents you from submitting to CRAN (which I don't know for sure; I thought that Notes were ok?). CRAN is a good place to send your packages because it does some quality control on the packages it accepts. As I said in my message to Yihui, if you think the test is wrong, you can argue about that and it might be changed, but if you can't convince the CRAN maintainers of the validity of your point, you shouldn't send your package there. There are plenty of other places (github, R-forge, etc.) where you can distribute it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
I know it is really bad, but the so-called good approach can be more
expensive than that, primarily because a package with a NOTE in R CMD
check is likely to be rejected by CRAN, or authors have to justify the
NOTE in the email.
For this particular case, I can imagine at least one case which can be
endless trouble to CRAN: if the package author A has talked to B to
use a hidden function in B's package, and B thinks that function is
relatively stable but does not want to export it; A may go ahead and
use it via :::. Both A and B understand that unexported function well,
then what should A do when submitting the package to CRAN? Should CRAN
continue adding rules for such exceptions?
In other words, "bad" practices almost always have exceptions and edge
cases. Of course, the decision is always in CRAN's hands, and I will
try to respect and follow it as a package author.
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA
On Fri, Aug 23, 2013 at 11:05 AM, Duncan Murdoch
wrote:
> On 13-08-22 11:54 PM, Yihui Xie wrote:
>>
>> Maybe it is not a good idea for R CMD check to check ::: at all, and a
>> warning in R-exts and ?':::' may well be enough. On the other hand, it
>> is just so easy to get around :::, because everybody can see its
>> source code:
>
>
> It's a really bad idea to write tricky code to subvert the tests. If the
> tests are wrong, you can argue for changes (and in this case you did, and
> changes were made), but if you can't give a convincing argument, you should
> follow the good practices that the repository policies enforce.
>
> Duncan Murdoch
>
>>
>>> `:::`
>>
>> function (pkg, name)
>> {
>> pkg <- as.character(substitute(pkg))
>> name <- as.character(substitute(name))
>> get(name, envir = asNamespace(pkg), inherits = FALSE)
>> }
>>
>> Then the package authors who really want to take the risk may start
>> another "hide and seek" game, e.g.
>>
>> `%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg),
>> inherits = FALSE)
>> 'stats' %:::% 'Pillai'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
Yihui, On Sun, Aug 25, 2013 at 7:53 PM, Yihui Xie wrote: > I know it is really bad, but the so-called good approach can be more > expensive than that > It is more expensive for you, yes. On the other hand, I'm pretty sure if everyone were running around circumventing whatever CRAN tests they were annoyed with at the time that situation would be enormously more expensive for the R community as a whole. > > For this particular case, I can imagine at least one case which can be > endless trouble to CRAN: if the package author A has talked to B to > use a hidden function in B's package, and B thinks that function is > relatively stable but does not want to export it; A may go ahead and > use it via :::. Both A and B understand that unexported function well, > then what should A do when submitting the package to CRAN? Should CRAN > continue adding rules for such exceptions? > > IMO, what you are describing is a straightforward situation in which the function should be exported. If a function is stable, the author is willing to have other people depend on it, and other people want to use it and would find it useful exporting it is the Right Way (tm) of doing that. What is your argument that it should not be exported in this case? To be clear I'm not arguing for outlawing :::, I DO think there are times when it is better than the available alternatives, but I think the type of selective exporting of functions just to the authors close friends that you are describing is toxic to the ecosystem of R packages as a whole. > In other words, "bad" practices almost always have exceptions and edge > cases. Of course, the decision is always in CRAN's hands, and I will > try to respect and follow it as a package author. > The thing about bad practices is that yes, they have exceptions and edge cases, but if the practice really is bad, most of the time someone thinks they are in such an exception/edge case situation, they aren't. This is not an attack on you or any individual person exhibiting "bad practices", but rather a descriptive statement about such things in general. Btw, this applies well beyond coding. Go read James Joyce and then ask an english professor if it's a good idea to write without any punctuation. They will say no, and that any student who did so in their class will be heavily penalized for it. And is that reasonable of them, even though things written without punctuation can be hugely influential high art? I would argue that it is. My opinion on the matter is that the rules are important to follow, even if they aren't quite optimal for any given situation. They aren't designed for any specific situation, to do a pretty good job in the vast majority of situations (and they are completely automated). To be honest I think there is a good case for willfull circumvention of the checks such as you describe being grounds for the package being ejected from CRAN, but its easy for me to say that since I don't have any power. Regardless of the reaction when it is detected (if ever, not sure how it ever would be, I'm sure CRAN is entirely uninterested in an arms race), that type of thing is bad behavior that is orders of magnitude worse than whatever the check was put in place to prevent. If a particular case really is an actual exception, I'm not convinced that having to actually talk to a CRAN person and justify the NOTE is an unreasonable price to be expected to pay. Again, I'm not arguing for the outlawing of :::, in fact I have a patch to R that implements the concept via NAMESPACE mechanics so you could have the package in imports instead of depends and prevent cluttering the search path when this is done. I don't think the situation your describing is a great case for the use of ::: though, and certainly not one that is a good case for CRAN allowing it, as I would imagine (without having any right to speak for them) that CRAN's position is that all packages and authors should be equal in terms of who gets to use what from whom. It is certainly my position on the matter (not that many people care about such things :P) ~G > Regards, > Yihui > -- > Yihui Xie > Web: http://yihui.name > Department of Statistics, Iowa State University > 102 Snedecor Hall, Ames, IA > > > On Fri, Aug 23, 2013 at 11:05 AM, Duncan Murdoch > wrote: > > On 13-08-22 11:54 PM, Yihui Xie wrote: > >> > >> Maybe it is not a good idea for R CMD check to check ::: at all, and a > >> warning in R-exts and ?':::' may well be enough. On the other hand, it > >> is just so easy to get around :::, because everybody can see its > >> source code: > > > > > > It's a really bad idea to write tricky code to subvert the tests. If the > > tests are wrong, you can argue for changes (and in this case you did, and > > changes were made), but if you can't give a convincing argument, you > should > > follow the good practices that the repository policies enforce. > > > > Duncan Murdoch > > > >> > >>> `:::` > >> > >> function (pkg, name) > >
