msa: object 'msaClustalW' of mode 'function' was not found
3
0
Entering edit mode
richel • 0
@richel-24067
Last seen 3.6 years 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")
mySeqs <- Biostrings::readAAStringSet(filepath)
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] : 
  ClustalW not found. Tip: install ClustalW

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 • 2.9k views
ADD COMMENT •
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 :-)

ADD REPLY •
0
Entering edit mode
richel • 0
@richel-24067
Last seen 3.6 years 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
ADD COMMENT •
0
Entering edit mode
UBod ▴ 290
@ubodenhofer-5425
Last seen 1 day 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?
ADD COMMENT •
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?

Thanks for your advice/pointers, Richel Bilderbeek

ADD REPLY •
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

ADD REPLY •
0
Entering edit mode

[edit: removed this duplicate reply]

ADD REPLY •
0
Entering edit mode
UBod ▴ 290
@ubodenhofer-5425
Last seen 1 day ago
University of Applied Sciences Upper Au…

The new version (1.31.2 on the devel branch) now solves that issue.
ADD COMMENT •

Login before adding your answer.

Similar Posts
Loading Similar Posts
Traffic: 651 users visited in the last hour
Content Search
Users
Tags
Badges
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6