Select() from stan_model clashes with org.Hs.egPFAM

Hello I suggested this time ago,

there must be a generic call to select() in stan_model() and this creates problem with another package org.Hs.egPFAM is defunct

stan_model(model_code = m)

Error: org.Hs.egPFAM is defunct. Please use select() if you need access to PFAM or PROSITE accessions.

Using this form PACKAGE::select() (within rstan) should solve this problem for biology-focused users


Pretty sure that this is an issue with rstan’s NAMESPACE file, that we’re missing an explicit importFrom or similar. Personally I do like the ::: solution but that’s more effort.

Namespace conflicts are just something inherent to R and community contributed packages. I teach my students to always if use package::function to ensure they are getting what they expect.

packages set up the order of their search path, this isn’t new and it’s also something your students should understand so they don’t do a lot of extra work out of fear:

Yup, I’m aware of that, and I tell students about it, but I teach them not to rely on having done it right, because it’s easy to mess up. I don’t consider being explicit about which package you intend to provide functions you use as being “a lot of extra work”. As I’m sure you’re aware, a little effort in your coding habits (inc. descriptive variable names, comments, and this kind of explicitness) can save your future self from much confusion/frustration.

In any event, my main point is that namespace collisions are inherent to R and while the rstan wiki might reasonably give users an extra heads-up (especially where it’s using particularly common verbs like “select” for function names), I don’t think there’s much else we can do about it.

We can fix the rstan namespace file, or do as you suggested, either one is fine. The namespace file has tree advantage of setting the search path for three function globally so you’re not running sed on your source if it needs to change.

We got a little off topic there, sorry, my original point was to say I agree and it would be great if you could do a small PR for rstan that fixes this issue.

Oh, my bad! I didn’t read the post carefully; now see that this isn’t a user namespace issue but indeed a misspecification in the rstan namespace file. Sorry for causing the tangent.

How to reproduce this problem? There is no function called select used in rstan.

$ grep select *.R
stan_demo.R:    else if(interactive()) MODELS <- select.list(MODELS)

Sorry for the late reply, today I will prepare the reproduction.


I am noticing that the error is coming up NOT because select() function is called, but because another (unknown) function is in common with org.Hs.egPFAM and causes an error in such package.

@mike-lawrence @sakrejda

When we identify the function (it is not select()) a quick fix could be modify only the call to that function as PACKAGE::function().

It is not needed to change all function calling in Rstan.

Said that, it is good habit to not import any library in R packages, but call every function with it’s explicit form. This is necessary for present and future compatibility with other software and user environments. More package are being produced and more and more functions with generic names will collide with those if not explicitly called. It is a tedious work, but will pay in the long run.

This part just isn’t true. It is not necessary, the other mechanism (the NAMESPACE file, properly used) also takes care of this problem with less repetition.

Good to know, I wasn’t aware that NAMESPACE can solve this issue. If you have some reference/link can you please share?

I missed the link above, thanks.

This thing:

Particularly the @importFrom directive for roxygen2

1 Like


Yes this seems to be the best approach

If you are using just a few functions from another package, my recommendation is to note the package name in the Imports: field of the DESCRIPTION file and call the function(s) explicitly using ::, e.g., pkg::fun(). Operators can also be imported in a similar manner, e.g., @importFrom magrittr %>%.

If you are using functions repeatedly, you can avoid :: by importing the function with @importFrom pkg fun. This also has a small performance benefit, because :: adds approximately 5 µs to function evaluation time.

IDK, we could have a real flame war over it, also :: vs. ::: :)

It’s the terrible practice of just importing whole namespaces on package load.

I wish more people were comfortable with namespace qualifiers in R. I was told we couldn’t really assume anyone was going to do things this way.

Me, either, but when I brought this up, Andrew won’t even consider it. I think that’s pretty much in line with what R programmers have come to expect.

That’s way too long to digest the link from Hadley.

Is there a way to let people use Stan’s extract function as extract(fit) that protects it from someone else writing an extract() function over a Stan fit object and importing it? That’s where the problems have shown up for us.

We’ve had all variations of this problem but you can’t even do that in c++ so… no? At least nothing that plays nice with the ecosystem. Personally as a user writing rstan::extract doesn’t bother me and I wouldn’t try to fight that battle. It’s not like people write reams of rstan code, they write reams of dplyr code for each rstan call. Or make it an object method.

Me either, but I’m not typical of an RStan user.