Julia: Deprecate importall

[tkelman]

Simplest part of #8000.
This doesn't seem like it needs to be syntax, should be possible to implement as a macro instead, maybe even living in a package if Base can be made to not need it. importall is usually a code smell when used in packages - if a dependency adds an export that happens to use the same name that you were using for some previously-module-local function, then you'll start extending functions that you may not have meant to.

By my count there are only 5 uses of this in Base other than in sysimg.jl. It might be desirable as we try to modularize and shrink Base to also rethink the 23 uses of importall that are currently in sysimg.jl, to encourage using the submodules of Base explicitly, more like they were packages (which most of them should be) rather than all part of the flat top namespace of Base.

[JeffBezanson]

I believe most uses in Base are actually instances of re-exporting (#1986). Probably some are unnecessary, and some are undesirable and the modules should be more separated.

[JeffBezanson]

We should possibly move Reexport.jl into Base.

[ararslan]

One issue I've found in writing the macro that would replace importall is that ..A doesn't parse except in the context of using/import/importall, so removing all special casing of importall would make it impossible to do relative importing (at least using the existing syntax).

[JeffBezanson]

I think we can do without a macro replacement. I don't think there are any cases where importall is really needed.

[KristofferC]

Very much agree.

[ararslan]

Actually I guess the deprecation target for importall should just be using, especially if we want to encourage (and possibly require) module qualification for extending.

[zsunberg]

I think we can do without a macro replacement. I don't think there are any cases where importall is really needed.

There is a use case for it - when you are trying to implement an interface defined in another package for a type that you created. People use this all the time with POMDPs.jl to make problem implementations cleaner (and we encourage it). Not saying that this decision is necessarily wrong, but I am sad to see it go.

I guess we'll make our own macro that does it specifically for POMDPs.jl...

[StefanKarpinski]

It might make more sense to have an ImportAll package that defines an @importall macro.

[NTimmons]

Here you go: ImportAll.jl

I needed this for a remapping project.

[zsunberg]

Thanks @NTimmons