Base.modules_warned_for silently removed in 1.8

General Usage
102

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)

  • 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.

4 Likes