# Precompilation errors while adding self-developed package to another package
**URL:** https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028
**Category:** New to Julia
**Tags:** question
**Created:** [December 20, 2024, 2:23pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028 "2024-12-20T14:23:41Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@jmaedler](https://discourse.julialang.org/u/jmaedler)
#### Post date: [December 20, 2024, 2:23pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/1 "2024-12-20T14:23:41Z")
Hi folks,
I am still fairly new to Julia… especially to package development. Currently, I am running into an issue while adding a package with some ModelingToolkit model library I developed myself. When I try to precompile I get errors for some dependencies:
I tried `instantiate`, `update`, `resolve`, and removing the folders in the compiled area. I am a bit lost. Do you have any explanations?
---
### Author:  [@brianguenter](https://discourse.julialang.org/u/brianguenter)
#### Post date: [December 20, 2024, 4:46pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/2 "2024-12-20T16:46:33Z")
Can you share your package? It’s almost impossible to help without specific details.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [December 20, 2024, 6:13pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/3 "2024-12-20T18:13:12Z")
> [@brianguenter](#):
>
> It’s almost impossible to help without specific details.
My educated guess: you’re using Julia v1.10 or older. And the package manager for some reason decided to favour an incredibly old version of `FFMPEG.jl` which required the super old package `BinaryProvider.jl` (when resolving an environment there are often several possible solutions and one has to be picked based on some heuristics, but these heuristics aren’t infallibile). One workaround is to add `FFMPEG@0.4` to your environment. Another option is to use Julia v1.11, which doesn’t allow installing `BinaryProvider` at all.
---
### Author:  [@jmaedler](https://discourse.julialang.org/u/jmaedler)
#### Post date: [December 23, 2024, 9:31am UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/4 "2024-12-23T09:31:18Z")
Thank you @giordano ! I guess exactly that is the issue. This is the `Project.toml` of my package:
```julia
name = "MTKWaterRunModels"
uuid = "e8d35126-f144-472a-a14d-eb099e605784"
authors = ["Jonathan Mädler <...> and contributors"]
version = "0.2.1"
[deps]
DifferentialEquations = "0c46a032-eb83-5123-abaf-570d42b7fbaa"
ModelingToolkit = "961ee093-0014-501f-94e3-6117800e7a78"
Pkg = "44cfe95a-1eb2-52ea-b672-e2afdf69b78f"
Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
SafeTestsets = "1bc83da4-3b8d-516f-aca4-4fe02f6d838f"
[compat]
julia = "1.10"
[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
[targets]
test = ["Test"]
```
Still, I am a bit confused why Julia out of the blue chooses to import these old version of the packages. The dependency responsible for this seems to be `Plots.jl`. So, is this potentially an issue of `Plots.jl`?
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [December 23, 2024, 12:13pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/5 "2024-12-23T12:13:28Z")
You didn’t show the full environment (`]status -m`), but presumably you also got an old version of Plots.jl, so another option is to add compat entry for it (which is always a good idea, besides being mandatory for packages in the General registry)
```toml
Plots = "1.40"
```
Side question, why does your package depend on Pkg.jl and Plots.jl at all?
---
### Author:  [@jmaedler](https://discourse.julialang.org/u/jmaedler)
#### Post date: [December 23, 2024, 1:33pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/6 "2024-12-23T13:33:26Z")
Ah ok 🙂 . I did not know about this `-m` flag for `st`. Unfortunately, I did the changes on the environment before running `st -m`. Now, I don’t know how to get back to the status which produced the error… 🤦♂️
Is there an automatic way to manage the compabitibility entries in the `Project.toml`?
Your question about `Pkg.jl` and `Plots.jl` is also very valid. `Pkg.jl` was still there from some experimentation during test development. I removed that. I use `Plots.jl` sometimes during test development to check the qualitative behavior before writing numeric tests. I removed that as well, but I am pretty sure that I will add this again from time to time to develop tests… is there a best practise for this? I was also already thinking about setting up an additional environment for tests to avoid this. Is that the way to go?
Thank you so much for your insides 🙂
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [December 23, 2024, 1:45pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/7 "2024-12-23T13:45:51Z")
> [@jmaedler](#):
>
> Is there an automatic way to manage the compabitibility entries in the `Project.toml`?
You can edit the file manually, but can also use the `compat` command in Pkg REPL mode, use `]?compat` to read the documentation.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [January 4, 2025, 6:53pm UTC](https://discourse.julialang.org/t/precompilation-errors-while-adding-self-developed-package-to-another-package/124028/8 "2025-01-04T18:53:02Z")
> [@jmaedler](#):
>
> use `Plots.jl` sometimes during test development to check the qualitative behavior before writing numeric tests. I removed that as well, but I am pretty sure that I will add this again from time to time to develop tests… is there a best practise for this?
Sorry, I had missed this question: one way is to put Plots.jl in a shared environment, like the global one (the default one when you don’t specify any environment), but I’d warn against putting heavy stuff in the global environment. You can have a shared environment like `@plots` and put Plots.jl there. Environments can be stacked, which allows you to use packages coming from different environments at the same time.