Rename just one of imported names with "using"

General Usage
, , ,
1

I want to use Luxor in my package, which also has a Point structure.
One alternative would be to rename the Point name from Luxor (e.g., as Pt) to avoid conflicts.
Luxor exports hundreds of other symbols, but Point is the only one I have conflicts with.
Is there a way to import all names exported by Luxor while just renaming one of them (in this case, Point as Pt) ?
I tried several combinations with no success.

2

I’m not sure this fully answers your question, but

using Luxor
const Pt = Luxor.Point

would seem to make the name conflict irrelevant, or not?

3

yes, thank you, but I still get the warning about an existing identifier.

4

I’d love to have an except keyword that you could use like

using GeometricalPredicates
using Luxor except: Point
using Luxor: Point as Pt
3 Likes
5

If struct Point end is in its own module (Foo) I don’t get such a warning. You mentioned that you were using Luxor from another package, so i would not expect a warning.

1 Like
6

A. S. @RaulDurand, this post specifically answer your Is there a way to import all names exported by Luxor while just renaming one of them (in this case, Point as Pt) question. However, I would suggest the approach here as the way to go.

A fast hack might be this:

import Luxor
import Luxor.Point as Pt

for x in names(Luxor)
    if x != :Point
        @eval import Luxor.$x
    end
end

Pt
# Luxor.Point

Point
# UndefVarError: `Point` not defined

Until somebody else presents a better solution you could use the above.

I think is safe to ignore the following warnings:

WARNING: could not import Luxor.latexboundingbox into Main
WARNING: could not import Luxor.latextextsize into Main
WARNING: could not import Luxor.rawlatexboundingbox into Main

Or you can add the three names above to the blacklist together with :Point and avoid getting the warnings.

P. S. Thanks for this fix.

2 Likes
7

You shouldn’t get warnings if you say which point you want. E.g.,

using Luxor, OtherPackageThatExportsPoint
const Point = OtherPackageThatExportsPoint.Point
const LuxorPoint = Luxor.Point
2 Likes
8

Should this approach replace what’s described in the manual?

julia> using .A: f as f

julia> using .B: f as g

Manual/Modules: Handling Name Conflicts

9

That is right.

The warning appears when I try something like this in a file outside a package:

struct Point
    x
    y
    z
end

using Luxor
const Pt = Luxor.Point

When I do that inside my package there is no warning.
Julia considers as Point my own definition and as Pt the Luxor definition.

10

This is better written

@eval import Luxor.$x
1 Like
11

Thanks all, guys, for the help and comments!

12

Thanks. Updated.

13

I would argue that the import/using-as syntax should be preferred because not all exported variables are const, and their reassignments are reflected by imported names, not variables assigned in other modules. The difference doesn’t matter in this specific case because the exported Point is const.

julia> module A
         export x
         x::Int = 0
       end;

julia> x::Int = -10; # let's make a name conflict

julia> using .A  # non-conflicting names would be imported fine
WARNING: using A.x in module Main conflicts with an existing identifier.

julia> using .A: x as xA  # rename for import
 │ Attempted to find missing packages in package registries but no registries are installed.
 â”” Use package mode to install a registry. `pkg> registry add` will install the default registries.


julia> const xA2 = A.x ; xA3 = A.x ;

julia> @eval A x+=1; # increment x in module A

julia> A.x, xA, xA2, xA3 # only the import links the names
(1, 1, 0, 0)
1 Like