# Warning both package a and b export the same function
**URL:** https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160
**Category:** General Usage
**Tags:** question
**Created:** [April 17, 2025, 10:51am UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160 "2025-04-17T10:51:21Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 17, 2025, 10:51am UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/1 "2025-04-17T10:51:21Z")
With Julia 1.10 I get the following warning:
```julia
WARNING: both VortexStepMethod and NonlinearSolve export "solve!"; uses of it in module KiteModels must be qualified
```
I don’t get it with Julia 1.11. Any idea why?
What is the best way to avoid this warning?
---
### Author:  [@hexaeder](https://discourse.julialang.org/u/hexaeder)
#### Post date: [April 17, 2025, 10:54am UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/2 "2025-04-17T10:54:06Z")
Not sure about the discrepancy between Julia versions, but to get red if the warning use explicit imports in KiteModels, I.e.
```julia
using NinlinearSolve: NonlinearProblem, solve!
```
Rather than importing everything which is exported.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 17, 2025, 10:57am UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/3 "2025-04-17T10:57:42Z")
The point is that we need both solve! methods in KiteModels. Could we make a change in VortexStepMethod to avoid this warning? Like adding:
```julia
import NonlinearSolve: solve!
```
to extend this method for a different type?
---
### Author:  [@hexaeder](https://discourse.julialang.org/u/hexaeder)
#### Post date: [April 17, 2025, 11:05am UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/4 "2025-04-17T11:05:28Z")
If you’ve resolve the name conflict (and thus the warning) you can use the long form including the module in source
```julia
using NonlinearSolve: .. what you need but solve!
using VortexStepMethod: .. what you need but solve!
# later in code
NonlinearSolve.solve!(...)
VortexStepMethod.solve!(...)
```
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 17, 2025, 11:12am UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/5 "2025-04-17T11:12:25Z")
I understand, but I would prefer to avoid that this problem appears in the first place. I think if I write:
```julia
using NonlinearSolve
import NonlinearSolve: solve!, solve
```
in VortexStepMethod then the problem will disappear even if I do
```julia
using VortexStepMethod, NonlinearSolve
```
in KiteModels
---
### Author:  [@PatrickHaecker](https://discourse.julialang.org/u/PatrickHaecker)
#### Post date: [April 17, 2025, 12:02pm UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/6 "2025-04-17T12:02:09Z")
I do not know about either of the packages. But what is it exactly what you want to achieve?
Do you want to end up with one function `solve!` and two methods defined for it?
In this case one package should make its function available (export or public) and the other package should `import` (not `using`) it or address it with its FQN like `OtherPackage.solve!` when defining the additional method
Or do you want to end up with two functions `solve!` with one method defined for each?
Then you should either use the FQNs or [rename](https://docs.julialang.org/en/v1.13-dev/manual/modules/#Renaming-with-as) at least one of both functions when bringing them into the namespace.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [April 17, 2025, 12:18pm UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/7 "2025-04-17T12:18:47Z")
I think changing the `solve!` function in `VortexStepMethod` to become `NonlinearSolve`’s, which originates in the lightweight dependency `CommonSolve`, is a breaking change. Even if those modules would define separate specificity sub-trees of methods by working on distinct types they own, it’s technically possible that someone relied on `solve!` being (at least) 2 distinct functions with separate method tables. It’s also likely nobody did so you could get away with it.
> [@ufechner7](#):
>
> `import NonlinearSolve: solve!, solve`
I’d recommend against `import` with names or bare `using` followed by extensions with unqualified method definitions because its presence changes whether the same method code extends another module’s function or tries to create a new one. [Opposition to unqualified extension methods](https://github.com/JuliaLang/julia/issues/39235) is more often mentioned for `import` with names, but bare `using` is a bit sneakier because whether the name was referenced beforehand is an additional factor:
```julia
julia> module D
export f
function f end
end;
julia> module E # first, no reference or definition
using ..D
end;
julia> D.f === E.f
true
julia> module E # no reference -> new function
using ..D
f() = 0
end;
WARNING: replacing module E.
julia> D.f === E.f
false
julia> module E # prior reference -> attempted extension
using ..D
f
f() = 0
end;
WARNING: replacing module E.
ERROR: invalid method definition in E: function D.f must be explicitly imported to be extended
```
I’d hazard a guess that you intended `VortexStepMethod.solve! === NonlinearSolve.solve!` in the first place, but bare `using` threw you off.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 17, 2025, 5:02pm UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/8 "2025-04-17T17:02:12Z")
To be honest, I do not understand what you wrote, that is too abstract for me.
I want to have a function solve! with two methods, one implemented by NonlinearSolve.solve! and one implemented by VortexStepMethod.solve!
That should be simple and straightforward.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 17, 2025, 5:17pm UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/9 "2025-04-17T17:17:18Z")
Does your `VortexStepMethod.solve!` follow the conventions and API of [CommonSolve.jl](https://docs.sciml.ai/CommonSolve/stable/)? If so, make `VortexStepMethod` depend upon CommonSolve, and make your VortexStepMethod `solve!` definitions explicitly extend CommonSolve’s function (typically by fully-qualifying `CommonSolve.solve!` in all your method definitions).
Then there’s only one function shared between both libraries and both can export it without trouble.
If you can’t do that, folks can still be `using` both packages together without this warning or major consternation — they just need to make sure that all usages are fully qualified or explicitly renamed.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [April 17, 2025, 5:21pm UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/10 "2025-04-17T17:21:05Z")
Very good point. This looks like the way forward.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [April 17, 2025, 6:30pm UTC](https://discourse.julialang.org/t/warning-both-package-a-and-b-export-the-same-function/128160/11 "2025-04-17T18:30:11Z")
> [@ufechner7](#):
>
> I want to have a function solve! with two methods, one implemented by NonlinearSolve.solve! and one implemented by VortexStepMethod.solve!
Before the currently proposed fixes, you had 2 distinct functions instead, and it is sounding more like it was unintentional. To adapt the D/E example to your case, I guessed that you expected
```julia
using NonlinearSolve
...
function solve!(...
```
to extend `NonlinearSolve.solve!`, but that instead made a new function with a separate method table in `VortexStepMethod`. Any of the fixes here would undo that and extend `NonlinearSolve.solve!` instead, but it seems like a breaking change, which isn’t as smooth for v1+ packages. I don’t expect it to break much; anyone who previously qualified or renamed the 2 distinct functions would still have working calls, just silently changed to the same function. But it’d break unusual reliance on the 2 functions being distinct, like a condition `solve_func !== NonlinearSolve.solve!` or `try`-`catch`-ing `MethodError`s for the wrong function, and it’d break anyone’s code that extended the 2 functions separately over their own types.