Open lmsimp opened 7 months ago
What about
> qf <- read.csv("hlpsms.csv") |> readQFeatures(quantCols = 2:11)
Checking arguments.
Loading data as a 'SummarizedExperiment' object.
Formatting sample annotations (colData).
Formatting data as a 'QFeatures' object.
Agree with Lisa. The readQFeatures function was widely used in our lab, including in published workflows and courses that we designed using QFeatures. I think that one of the great things about QF is the simplicity, so this additional step seems to me unnecessary. It'd be great if the functionality to read directly from files could be added back.
I will look into it, but let me highlight some other aspects of your request:
You say that
I think that one of the great things about QF is the simplicity, so this additional step seems to me unnecessary.
With regard to readQFeatures()
, the example showed above is trivial, which is something you seem to appreciate. But we have files that are read and parsed into hundreds of assays. This is a situation that needed to be (and has been) simplified, in particular with regard to sample meta-data incorporation. In such non-trivial situations, we never read the data directly from a file; in the most simple cases, using readSummarizedExperiment()
also just works.
You would like the old behaviour to be added. But please, keep in mind that this seemingly simple request adds some non-trivial work on my busy plate. I don't know how easy it will be to add what you want, but I will probably have to:
read.csv()
function;readQFeatures()
and readSummarizedExperiment()
to use the helper function;readQFeatures()
;From what I gathered from the original request, the only thing that you need to change on your side is the suggestion I proposed:
readQFeatures(file, quantCols = e)
to
read.csv(file) |> readQFeatures(quantCols = e)
This applies to your teaching material [*], the F1000research paper (which you can update to a new version) and possibly more. But there is no way for me to guarantee backwards compatibility for code/material I don't maintain/know about. But in general, I do make efforts to maintain backwards compatibility.
And last but not least, which despite this issue might be good news, we are working on a dedicated import app, that aims at making data import (especially the more difficult cases) as easy as possible.
[*] You should anyway update your material and start using quantCols
instead of ecols
, that is likely going to be deprecated in a release or two.
Hi Laurent,
Completely understand how much work it is to develop/maintain all of your packages and appreciate that no task is trivial. We were simply disappointed to see what we had considered very useful functionality removed.
Don't forget that you can always
> readQFeaturesCCP <- function(filename, sep = ",", quantCols, ...)
read.csv(filename, sep = sep) |>
readQFeatures(quantCols = quantCols, ...)
> readQFeaturesCCP("hlpsms.csv", quantCols = 2:11)
Checking arguments.
Loading data as a 'SummarizedExperiment' object.
Formatting sample annotations (colData).
Formatting data as a 'QFeatures' object.
An instance of class QFeatures containing 1 assays:
[1] quants: SummarizedExperiment with 3010 rows and 10 columns
(pinging @StijnVandenbulcke who raised the same issue to me.)
Hi @lmsimp and @Charl-Hutchings,
I'm sorry to hear that our recent changes negatively affected your teaching and research material.
I however agree with the points mentioned by Laurent. The refactoring of readQFeatures()
resulted from quite some discussions, and we deliberately decided to remove functionality to read tables from files. In my experience and usage of readQFeatures()
, I always use read.table()
(or functions alike) because i. I always double check the table was correctly imported, ii. I always forget what quantCols
should be; iii. I usually use grep()
on the imported column names or look at the column indexing after printing the colnames to the console when defining quantCols
, hence requiring the data to be already imported. I can argue this is the best practice, and in fact, this is also what you demonstrated in your recent workflow paper.
Of course, this is my opinion based on a small sample (a few lab members/collaborators and me). I would be open to spend some time reverting to importing data from file if you could provide us with a convincing use case.
Hi Laurent,
I have been trying to use the
readQFeatures
function in the latest release to read in data from an external file e.g. from third party .txt file. To date, this is what we have been doing in our workflows when usingQFeatures
but now I see this is no longer supported and only now is an option withreadSummarizedExperiment
?Would you consider adding the option back to
readQFeatures
for users so we can create aQFeatures
object directly from an external file as perreadSummarizedExperiment
?Best,
Lisa
An example,
This works perfectly as the data is already a
data.frame
Create an example .csv and write it locally a test data
If I now try and read from a .csv file I get the following errors
Also, the same if a character is specified for the
quantCols
Works perfectly for SEs