Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completely axe reshape2 from code #3549

Closed
MichaelChirico opened this issue May 7, 2019 · 6 comments · Fixed by #3577
Closed

Completely axe reshape2 from code #3549

MichaelChirico opened this issue May 7, 2019 · 6 comments · Fixed by #3577
Milestone

Comments

@MichaelChirico
Copy link
Member

As mentioned in #3542, reshape2 is dead since a year ago.

We removed it from suggests but still have some snippets like:

    ns = tryCatch(getNamespace("reshape2"), error=function(e)
         stop("The dcast generic in data.table has been passed a ",class(data)[1L]," (not a data.table) but the reshape2 package is not installed to process this type. Please either install reshape2 and try again, or pass a data.table to dcast instead."))
    ns$dcast(data, formula, fun.aggregate = fun.aggregate, ..., margins = margins,
             subset = subset, fill = fill, value.var = value.var)

I don't think it makes sense to support such functionality anymore.

Question is, are we safe to just get rid of it right away, or do we need to lifecycle it out?

@jangorecki jangorecki self-assigned this May 14, 2019
@jangorecki
Copy link
Member

According to comment (probably very old one) in melt

    # if data is not data.table and reshape2 is installed, this won't dispatch to reshape2's method;
    # CRAN package edarf and others fail without the else branch

Question is, should we create generic methods for dcast and melt?

@jangorecki jangorecki removed their assignment May 14, 2019
@MichaelChirico
Copy link
Member Author

MichaelChirico commented May 14, 2019 via email

@MichaelChirico
Copy link
Member Author

lines 98-108 of NAMESPACE?

@MichaelChirico
Copy link
Member Author

MichaelChirico commented May 22, 2019

By default, if any of the columns to be melted are of type factor, it'll be coerced to character type. This is to be compatible with reshape2's melt.data.frame.

Now that we're taking ownership of dcast/melt, do we want to continue this backward-compatibility?

Of course we'd have to go through a deprecation cycle, but ultimately do we agree with this behavior?


Ditto:

warning("To be consistent with reshape2's melt, id.vars and measure.vars are internally guessed when both are 'NULL'. All non-numeric/integer/logical type columns are considered id.vars, which in this case are columns [%s]. Consider providing at least one of 'id' or 'measure' vars in future.", CHAR(STRING_ELT(concat(dtnames, idcols), 0)));

@lionel-
Copy link

lionel- commented Dec 5, 2019

FWIW reshape2 is not dead nor deprecated, it is only "retired". This means that development has stopped but it continues to be maintained on CRAN and will continue to work for the foreseeable future.

@hadley
Copy link
Contributor

hadley commented Dec 5, 2019

You can see our lifecycle definitions at https://www.tidyverse.org/lifecycle/#retired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants