# Explicitly disable extensions in Project.toml
**URL:** https://discourse.julialang.org/t/explicitly-disable-extensions-in-project-toml/136126
**Category:** Internals & Design
**Tags:** question, pkg
**Created:** [March 11, 2026, 3:48am UTC](https://discourse.julialang.org/t/explicitly-disable-extensions-in-project-toml/136126 "2026-03-11T03:48:49Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 11, 2026, 3:48am UTC](https://discourse.julialang.org/t/explicitly-disable-extensions-in-project-toml/136126/1 "2026-03-11T03:48:49Z")
Could it make sense to explicitly disable package extensions?
For my project, for example, precompiling the [DataInterpolationsMakieExtension](https://github.com/SciML/DataInterpolations.jl/tree/master/ext) takes a long time even though I do not need it.
Installing and pre-compiling my [Project](https://github.com/OpenSourceAWE/KiteModels.jl) 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?
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [March 11, 2026, 4:46am UTC](https://discourse.julialang.org/t/explicitly-disable-extensions-in-project-toml/136126/2 "2026-03-11T04:46:07Z")
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.