Could it make sense to explicitly disable package extensions?
For my project, for example, precompiling the DataInterpolationsMakieExtension takes a long time even though I do not need it.
Installing and pre-compiling my Project takes about 15 minutes on a fast PC. If I could cut this time by 3 minutes by disabling unused extensions, I would be happy.
Do you think having a [Disabled] section in Project.toml would make sense?
No, extensions are an intended part of method dispatch, and removal is akin to type piracy. Let’s say A defines function foo(x), B defines struct Bar, and ABExt defines function foo(x::Bar). Let’s then say C and D each depend on A and B, but C disables ABExt. The foo(::Bar) call dispatches to different methods in environments with only one of C or D, so C and D together in one environment would break each other like type piracy would. Importing D after C is more plainly equivalent to type piracy because the function foo(x::Bar) definition requires evaluating D instead of just A, B. Pkg could prevent C and D from coexisting, but routine updates would grind to a halt whenever a possibly very indirect dependency decides to disable an extension to save time.
I’ve had a similar thought about disabling precompile workloads or native code caching, but I wouldn’t know how that could work in practice (only enabling direct dependency’s workloads, manually specifying dependencies for workloads, similar incompatibility issues from specifying it for a dependable package instead of a top-level package, etc). But back to the topic at hand, it surprised me that DataInterpolationsMakieExt took a long time because I’m not seeing a workload there, just 5 methods.