Correct using of Reexport

General Usage
, ,
1

Hello,

I’m developing the QuantumToolbox.jl package, to simulate quantum systems in Julia. This package mainly uses linear algebra operations on sparse and dense arrays. Thus, I have those two packages as dependencies.

Moreover, I was using Reexport.jl to re-export those package when I do using QuantumToolbox. In this case they are already imported.

I was wondering if this is a good procedure. I saw that the functions are exported as QuantumTollbox.eigen instead of LinearAlgebra.eigen for example.

Is this still a good way to proceed?

I’m almost releasing the stable channel, and I would like to set these dependencies definitely.

1 Like
2

Could you provide a specific example? Assuming your code looks like the following, the eigen function being exported can be called directly without a module prefix.

module test
using Reexport
@reexport using LinearAlgebra
end
using .test
methods(eigen)

The above example is how I usually use reexport.

3

Yes exactly this example.

But I was wondering if this is a good way to structure the package, or maybe just using Reexport only when there are different packages under the same ecosystem, like DifferentialEquations.jl

4

I see what you mean. @reexport is best used to export submodules within your module, or if your module depends on another module you wrote (same ecosystem).

The base libraries and some common packages are best not exported from your modules, imagine the redundancy of this operation if everyone exported linear algebra libraries from their modules. Unless you are quite sure that packages written by others will certainly not export the same packages as yours again. However, this is not absolute, I think its just a matter of code style.

5

Thank you for your reply.

What happens if also other packages export the same Base libraries?

6

Nothing happens, it just amounts to LinearAlgebra being using twice. That’s why I say it’s just a matter of style. You might want to hear from others in the community.

One advantage of not exporting is that users can explicitly see which base libraries they are using in the top-level script.

7

Could you be more specific for the last sentence?

8

Taking your package as an example, the user may write the following code:

using QuantumToolbox
eigen(...)

If one can use eigen, is it QuantumTollbox.eigen or LinearAlgebra.eigen? If it’s the former, that means your package overloads the eigen method. If the latter, it means that your package reexports eigen.

However, as long as you make it clear in your documentation which packages are reexported, it’s fine.

using QuantumToolbox, LinearAlgebra
eigen(...) # OK, I'm sure I am using LinearAlgebra.eigen here.
9

Am I missing something here? If QuantumToolbox implements an eigen function, depending on the arguments, either eigen in QuantumToolbox or LinearAlgebra can run due to multiple dispatch.

Edit: the above refers to the following quote specially

The comment seems not accurate: the line can call eigen method defined in QuantumToolbox.

10

We are just overloading many LinearAlgebra functions like LinearAlgebra.eigen(::SomeCustomOperator) = ...

11

I still don’t understand exactly why we should avoid reexporting those libraries.

Our main use is to extend LinearAlgebra methods to our types like

LinearAlgebra.tr(A::QuantumObject) = ...

and others.

Could you make an example were this is actually a problem?

12

I’m sorry that I didn’t get back to you in time. I also saw another similar post. In general, I have an open mind on this issue, and although I personally tend to only use reexport in the same ecosystem, I am not at all opposed to you using reexport in any situation. as I said at the beginning, “ I think its just a matter of code style. ”

We had a long debate in this post, and I took the position of “export only packages from the same ecosystem”. And in the end? As you can see, this argument is not infallible, and there is no reason why it must be done. All I did was explain some of my points to your follow up question.

Good luck with your package development.

1 Like
13

Thank you. I will decide with the other maintainers what to do.