msa: object 'msaClustalW' of mode 'function' was not found
2
0
Entering edit mode
richel • 0
@richel-24067
Last seen 17 months ago

msa seems to be just the thing I need! With this post, I hope to make it better for people that (also) start to use it.

I found the help for the msa::msa funcion (?msa::msa) and ran the first example code:

filepath <- system.file("examples", "exampleAA.fasta", package="msa")
msa::msa(mySeqs)


The error I got was:

Error in get(as.character(FUN), mode = "function", envir = envir) :
object 'msaClustalW' of mode 'function' was not found


I feel this error should be a bit more helpful, as it is from a (in this case, my first) msa example. I predict the error should be mentioning to me that I need to install ClustalW on my local computer, something like:

Error in [some function] :


If my prediction is correct, I hope msa will help its new users better by giving a more helpful error message.

Else, this message is a regular bug report :-)

Thanks, Richel Bilderbeek

msa • 733 views
0
Entering edit mode

P.S. I do see I have ClustalW installed:

\$ clustalw version

CLUSTAL 2.1 Multiple Sequence Alignments


Therefore, I really need to search the web for what to do first :-)

0
Entering edit mode
richel • 0
@richel-24067
Last seen 17 months ago

I found the error, as I have found a workaround.

The workaround is to do:

library(msa)


The error is caused by the missing of a namespace specifier (msa::) somewhere in the code.

I hope this will be fixed: from CRAN rules, a testthat test must not modify the global environment of a user. Sure, msa is not on CRAN and this may intentionally be so forever, yet the rule is there for a reason, among others, to prevent name clashes.

I encourage the msa developers to run the example code as posted above, without calling library(msa) first, so to prevent name clashes.

Thanks and cheers, Richel Bilderbeek

0
Entering edit mode
UBodenhofer ▴ 290
@ubodenhofer-5425
Last seen 12 weeks ago
University of Applied Sciences Upper Au…

Richel, thanks for reporting this issue! First of all, the 'msa' package does not require any additional software packages. All three methods, ClustalW, ClustalOmega, and Muscle are compiled into the package and are available inside the package.

You correctly point out that calling library(msa) fixes the issue. To be frank, I was not aware that a package's functions should work even without attaching the package's namespace. Can you give me a pointer to the CRAN rules where this is stated?

0
Entering edit mode

Hi Ulrich,

Thanks for your reply! How awesome that 'msa' has all these tools compiled with it!

[...] I was not aware that a package's functions should work even without attaching the package's namespace. Can you give me a pointer to the CRAN rules where this is stated?

Thanks for this great reply: it made me check my assumptions as well.

To be sure regarding the CRAN rules, I posted a question to the R CRAN package develop email list (copy-pasted below for reference) and I will let you know the response.

Thanks for msa and I'll keep you posted, Richel Bilderbeek

Email

Should a package run without calling library?

1 September 2020 09:43 4 KB From: Richel Bilderbeek To: r-package-devel@r-project.org

Dear fellow R package maintainers,

I would enjoy your advice to clarify a CRAN policy issue.

The question is: should a package be able to work, when calling its exported functions using the scope operator? Or, in the example code below, should #1 work?

# 1. Scope operator: should this always work?
mypackage::myfunction()

# Possible error message:
# Error in myfunction() :
#  object 'myhiddenfunction' of mode 'function' was not found

# 2. Calling library first
library(mypackage)
myfunction()


I feel the answer is 'yes, #1 should work', as I feel this is only indirectly a CRAN repository policy [1] , the IMHO relevant one which I quote: 'Packages should not modify the global environment (user’s workspace).'. This means that if I have a function that calls mypackage::myfunction, it will call library:

#' Function in another package, that depends on my package
do_something <- function() {
library(mypackage)
myfunction()
}


So, should a package be able to work, when calling its exported functions using the scope operator?

0
Entering edit mode

Ah, I see that, indeed, a package's functions should work even without attaching the package's namespace, according to Uwe Ligges (one of the most important CRAN contributors):

Email

Re: [R-pkg-devel] Should a package run without calling library?

1 September 2020 10:02 7 KB From: Uwe Ligges To: [...]

On 01.09.2020 09:43, Richel Bilderbeek wrote:

Dear fellow R package maintainers,
I would enjoy your advice to clarify a CRAN policy issue.
The question is: should a package be able to work, when calling its exported functions using the scope operator? Or, in the example code below, should #1 work?

# 1. Scope operator: should this always work?
mypackage::myfunction()
# Possible error message:
# Error in myfunction() :
# object 'myhiddenfunction' of mode 'function' was not found


Yes.

# 2. Calling library first
library(mypackage)
myfunction()



Yes.

I feel the answer is 'yes, #1 should work', as I feel this is only indirectly a CRAN repository policy [1] , the IMHO relevant one which I quote: 'Packages should not modify the global environment (user’s workspace).'. This means that if I have a function that calls mypackage::myfunction, it will call library:


No, it can import from the namespace, i.e. it loads the package, but does not modify the search path (i.e. does not attach the package).

Also note the workspace (=.GlobalEnv) is not the search path.

Best, Uwe Ligges

0
Entering edit mode

[edit: removed this duplicate reply]