Why is precompilation turned off for tagged releases?

[pearlzli]

I noticed that precompilation is turned off for tagged releases and then subsequently turned back on (e.g. 531a38b and 78e3b69). What is the reasoning for this?

I'm working on a package which depends on Plots, and our Travis builds are failing because we have __precompile__(true) and Travis installs the latest release of Plots. I'd ideally like to keep precompilation for this package - is there any way to get around this?

[apalugniok]

This won't be a full answer as I don't know all the details. I think the metadata maintainers want us to keep precompilation off due to the conditional dependencies in the package. But precompilation seems to work fine for Plots so on master we keep it on.

Long term solutions involve reorganising Plots as discussed in #918.

[mkborregaard]

That's right. The issue is that things will break if you load e.g. GR withgr(), and the package is updated in the meantime - I've never experienced issues with in practice, though. But @pearlzli why does your package depend on Plots? Most of the time it is sufficient to depend on RecipesBase, which is a completely safe dependency.

[pearlzli]

I wasn't aware of RecipesBase, so I was able to rewrite some of our plotting functions using recipes. However, one plot I'd like to create involves using groupedbar from StatPlots, which in turn relies on Plots. Is there a way to get around this without reimplementing groupedbar myself?

[mkborregaard]

Nope, not at the moment :-(
I think StatPlots should drop it's dep on Plots, though, that would make it easier to reuse the recipes there.