> We did have an attempt at that for some versions, but I don't think it ever
> achieved all of its goals, and we've dropped it.
Yes, I remembered it used to be possible to do versioned installs, but
I don't think you could ever have them loaded simultaneously.
> I'm not sure it would be "optimal" even if it was completely implemented.
> It introduces a lot of complexity. Simplicity is better, even if it is
> sometimes more work.
But the current simplicity also makes more work - each time a new
package is uploaded to CRAN all dependencies need to be rechecked.
That would not be the case if packages could specify versioned
dependencies.
Another problem that I face is that I often release a new version of
plyr at the same time as a new version of ggplot2. The new version of
ggplot2 requires the latest version of plyr, but
install.packages("ggplot2") will not reinstall plyr if it is present
but an outdated version. Dependencies are checked at build time, but
not install time.
>> My work around of renaming packages after API breaking changes is
>> definitely a sub-optimal fix.
>
> Yes. The optimal solution would be for all the packages that use yours to
> update to the latest version. More work, but they end up in a better place.
> (Or even better, if all package writers got it right the first time :-).
The problem is not just packages, but reproducible code in general.
As it stands currently, to make sure a script continues to work in the
long run you need a library containing the versions of the packages
you used at the time. It would be a little easier if you could do
library("ggplot2", version = 0.85) or similar. (Ignoring the other
difficulties of capturing the current version of R, other system
libraries, OS, hardware etc).
Generally, the absence of versioned dependencies makes it extremely
difficult to aggressively improve the design of a package. You are
locked into your first attempt at an API because it is so difficult
for users to work with the non-latest version. Namespaces help with
this a little (by not exporting experimental functions), but I find
there are many initial design decisions that I now regret in ggplot2,
and I can not easily remedy them without breaking large amounts of
existing code or starting work on ggplot3.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
