# Base.modules\_warned\_for silently removed in 1.8 **URL:** \ **Category:** General Usage\ **Tags:** breaking\ **Created:** [April 5, 2022, 7:17am UTC](https://discourse.julialang.org/t/base-modules-warned-for-silently-removed-in-1-8/79035 "2022-04-05T07:17:53Z")\ **Posts on this page:** 1\ **Showing post:** 102

**Author:** ![essenciary](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/essenciary/32/210469_2.png) [@essenciary](https://discourse.julialang.org/u/essenciary)\ **Post date:** [June 10, 2022, 7:44am UTC](https://discourse.julialang.org/t/base-modules-warned-for-silently-removed-in-1-8/79035/102 "2022-06-10T07:44:34Z")

Long story short: - Genie apps have 2 main components - the Genie package and the user app (a module with multiple submodules). These 2 parts cooperate, the user app using features exposed by Genie, and Genie providing APIs to manage user app files. - since work on Genie started in Julia 0.5, before `Pkg`, it was affected by multiple breaking changes in Julia’s code loading system. - after the introduction of `Pkg`, `LOAD_PATH` was used to load user code/modules by adding their folders to `LOAD_PATH` and this worked well for many years and for many Julia versions. - I think around v1.6 the user code loading started to throw a warning (why would it start to warn with a minor release, no idea) and a user suggested `Base.modules_warned_for` in order to get rid of the warning. (An attempt to figure out what changed here [Module correctly loaded from LOAD\_PATH but still getting a dependencies warning](https://discourse.julialang.org/t/module-correctly-loaded-from-load-path-but-still-getting-a-dependencies-warning/58087)) - That made sense so I introduced the proposed patch - tests passed, and the code worked as previously so no big deal with a warning I thought. - Yes, I personally introduced the patch as some people here uselessly spent time to dig - sorry, I didn’t mean to mislead, I remembered it was a PR but I guess it was just a proposal. - No, I did not go through the still-unbelievable requirement of manually checking if this function was documented/exported/in-the-manual. I have not considered it then because even now that I know of it, this requirement for manual check, for a modern programming language, in 2022, is so ridiculous and absurd that it leaves me speechless. - Moving on to v1.8, it appears that not only has `modules_warned_for` been removed, causing the breaking change, but the user code loading strategy has changed and the user code loading that used to warn out, now doesn’t work at all. - So it’s not specifically about `modules_warned_for` nor about Genie as I’ve actually solved the code problem in the soon to be released Genie v5. I took this opportunity to completely refactor the user code loading, move many modules into out-of-core plugins, get rid of many compromises done over so many Julia versions, etc, etc so it’s a nice cleanup and I’m happy with the outcome that this change has forced. - So it’s a discussion about principles and methodology with a few related topics: 1/ having a way to programatically check if a function/property is private or public at module and package level (by failing tests/not compiling) 2/ raising the point that, IMO, the proposed solution of manually checking the manual/documentation/export status of every function and property is a ridiculous proposal. (I know “ridiculous” is a strong word but I can’t think of anything else: a programming language is supposed to automate tasks, how can it have a policy to create a requirement for a human to manually check every function and property?!! My mind can not comprehend.) 3/ the fact that, to my experience, `modules_warned_for` is not the only breaking change introduced - as per my experience, code loading strategies have also changed, leading to breaking changes. So overall, much more consideration should be given to changes. --- _[View the full topic](https://discourse.julialang.org/t/base-modules-warned-for-silently-removed-in-1-8/79035)._