# \[ANN\] UseAll.jl – Temporarily Demodularize Julia Code

**URL:** <https://discourse.julialang.org/t/ann-useall-jl-temporarily-demodularize-julia-code/136432>\
**Category:** Package Announcements\
**Created:** [March 28, 2026, 7:53am UTC](https://discourse.julialang.org/t/ann-useall-jl-temporarily-demodularize-julia-code/136432 "2026-03-28T07:53:49Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [March 29, 2026, 4:02pm UTC](https://discourse.julialang.org/t/ann-useall-jl-temporarily-demodularize-julia-code/136432/7 "2026-03-29T16:02:38Z")

</div>

> [@goerz](#):
>
> The caveat in the README
> 
> > Do not use `UseAll.jl` in a regular package.
> 
> would be a strong argument for _not_ putting this into the General registry.

I agree with the logic, but isn’t the caveat a bit extreme to begin with? Say there’s a package that does `@useall` its dependencies and does all the crazy things that PatrickHaecker is warning against. That mostly doesn’t matter to the package’s users unless ExportAll.jl, which _is_ in General, is also used to expose all those names to them. There’s an argument here that a package developer is free to do generally bad practices (like relying on internals) when it makes sense and isn’t exposed, and a runtime warning wouldn’t really help then. It’s already quite easy to check a package’s Project.toml for UseAll, and it’d show up in Manifest.toml if an indirect dependency ever uses it (but factcheck me if test dependencies also show up, which we may want to ignore). Dependency tree reflection for a particular dependency would be nice though; I think there was a related package announced recently.

> [@PatrickHaecker](#):
>
> Note the missing dot, i.e. `@useall MyModule` instead of `@useall .MyModule` which is needed, as the latter one does not parse and therefore cannot be used. This is normally not an issue, as most of the time you will be working with packages anyway which never need the dot prefix.

You could support a secondary syntax `@useall using .MyModule` like Reexport.jl.

> [@PatrickHaecker](#):
>
> Alternatively, you can switch the currently active module in the REPL by entering `MyModule` and hitting `<alt>`+`<m>`.

That would actually work great in conjunction with this package because it’s easy to run into import name conflicts upon multiple implicit imports, and `@useall` introduces more names per module that could conflict. There is an element of chance here, but the chance is very high for the standardized `@main()` resolving to `:main`. Dumping Main into each package would be less conflicting than dumping many packages into Main, but namespace baggage in our actual projects is a session-irreversible source of bugs. Either way, it’d necessitate a time-consuming session restart.

To minimize the number of possibly conflicting modules and to partially put the “temporarily” in the title, we can make and switch to throwaway submodules in Main just for REPL experimentation, and each one can isolate a pair of `@useall Main; @useall MyModule`. If that still causes issues, we can make another Main submodule and rename some imports instead of `@useall Main`, maybe work with new isolated globals. Those modules aren’t really temporary because they’re all kept alive in the session, but they don’t affect other modules and we can switch away for the rest of the session.

---

_[View the full topic](https://discourse.julialang.org/t/ann-useall-jl-temporarily-demodularize-julia-code/136432)._