Describe how to export downstream

[mmikhasenko]

Here is what I do in FourVectors.jl

# Access the list of function names
const ALL_GETTER_FUNCTIONS = vcat(
    collect(LorentzVectorBase.FOURMOMENTUM_GETTER_FUNCTIONS),
    collect(keys(LorentzVectorBase.FOURMOMENTUM_GETTER_ALIASSES)),
)

# Loop over each function name and import and export it
for func_sym in ALL_GETTER_FUNCTIONS
    # Import the function from LorentzVectorBase
    @eval import LorentzVectorBase: $(func_sym)
    # Export the function from this module
    @eval export $(func_sym)
end

[Moelf]

use https://github.com/simonster/Reexport.jl?tab=readme-ov-file ?

[mmikhasenko]

I do not think you want to list all methods and their aliases manually.
How do you mean using @reexport ?

[szabo137]

I think it is not a good idea to (re)export every getter function. Currently, we've decided to use short names like x,y,z,t,E,px,..., which can mess up the namespace for all packages with using FourVectors.jl.

To have a better exportability of the getter functions, we must rename them, e.g. x->x_component, so x_component can be safely exported.

[szabo137]

I do not think you want to list all methods and their aliases manually. How do you mean using @reexport ?

The @reexport macro just grabs all exports of one package (e.g. LorentzVectorBase) and exports them again on a depending package (e.g. FourVectors.jl). However, since in the current status, LorentzVectorBase.jldoes not export the getter functions (because of the reason above),@reexport` will not help.

[mmikhasenko]

Currently, I decided to do the following:

• I looked over calls and export in a customary package, these that are unlikely to conflict with anything downstream,

https://github.com/mmikhasenko/FourVectors.jl/blob/main/src/FourVectors.jl#L10-L35

I will add a comment,

None of the methods of the package are exported. To call them, one always needs a LorentzVectorBase. prefix.
These methods can be exported in a customary package exp

module Custom4Vector

import LorentzVectorBase: invariant_mass
export invariant_mass

end

[szabo137]

Maybe we should think about that exporting a subset of getter functions, which are unlikely to produce conflicts. We could use more aliases, if this is not possible for all getter currently supported.

The downstream packages could just use Reexport.jl.

module DownstreamModule
using LorentzVectorBase
using Reexport 
@reexport LorentzVectorBase #reexports all symbols we make public 

# implement LV interface for your custom type 

end