Looks like Base.modules_warned_for no longer exists in 1.8? I can’t find it mentioned in the news. What’s the status please and what’s the recommended way for replacing it?

That was an unexported, undocumented internal variable - they’re not guaranteed to be around in any version. It got removed here: https://github.com/JuliaLang/julia/pull/42822

A lightweight way to improve on what already exists would be: Exported-public - anything exported is deemed public Private - anything not exported is deemed private by default Not-exported public - need a keyword or macro to mark entities as not exported but are part of the API. That means the degree of change necessary to implement is restricted to methods you want to be public but not exported, which should be relatively few. Tooling can warn if private entities are used from another module, rather than have any enforcement by the compiler. Have another keyword or macro that allows it to be suppressed, either for a particular line, block of code, or whole module. No need to enforce a naming convention that would require ecosystem-wide refactoring of all internal code.

Python at least has more of a culture and tooling (linters, etc.) to support the idea of private methods and attributes. Just one example: Some linters will require you to document a method unless it starts with _. The same convention is sometimes used in Julia. But, it’s much less widespread, and more poorly supported by tooling.

One thing I can fully agree on is that it sucks when someone contributes code and your library breaks a year later because they snuck in an undocumented internal Base method to make something work but didn’t make a note or add a check to the tests. It makes sense to want some guard against that beyond proofreading code at 100% efficiency. It just doesn’t make sense to appropriate OOP access modifiers for this, Julia doesn’t have classes for access modifiers to encapsulate. Roughly speaking, OOP encapsulation designates what components of a class are accessible by other classes (public methods and few fields) and what are confined implementation details (private fields, methods, even nested classes). It’s not the same, but a non-OOP encapsulation is accomplished by modules separating global scopes, exporting select names, or importing select names. That’s why exported names came up in the thread as a hint of public API (though still not as authoritative as documentation). The talk about access modifiers is suggesting that we should apply to multimethods in modules something designed for members in classes. There’s a lot wrong with this: Internals aren’t confined to their home module, they’re free to be exported within the package to the convenience of the developer and out of the users’ sight. The unit in which an internal operates is not a module, it’s the package. So you could invent access modifiers on a package level…if you’re prepared to sacrifice the ability to inspect and test internals easily. There’s also a complicated unsettled debate on how to develop and test (or not) private members. Unlike a singly dispatched method confined to a class, a multimethod’s definition can be scattered, even across packages. What happens when some methods are marked @private and the others are marked @public? This straightforward inspiration is just a footgun. What about global variables and macros? Macros aren’t even variables or instances. There’s been some talk about informal conventions like leading underscores, but I’m not sure it’ll solve the issue at hand. It saves someone from checking documentation or exports to know if something is public vs internal, but a proofreader can easily overlook it anyway. Without printing warnings or throwing errors, this’ll only make a very rare mistake somewhat easier to spot. And remember that all our internals would have leading underscores, so when you search the text ._, most of it would be your internals. And if we want to make an internal public in the next version? Time to find-replace-all every file.

[image] Sukera: PkgEval is already run for every package in existence before a release and if your package is found to break due to a change in API, you will get notified/the change will be reverted (depending on severity). Thats’s the first time I hear about this notifications thing. Whats’s the notification mechanism, and how to opt into it?

[image] aplavin: Thats’s the first time I hear about this notifications thing. Whats’s the notification mechanism, and how to opt into it? No need for opt in. Last I checked, it was either an issue in your repo, or a revert of the offending change in Base, provided it was an accidental API breakage, not a change to an internal function that doesn’t have stability guarantees. Other cases are when you test for exact numerical reproducibility of e.g. the default RNG number stream or numerical results based on that.

[image] Benny: it sucks when someone contributes code and your library breaks a year later because they snuck in an undocumented internal Base method Possibly, but note that in this particular case, @essenciary himself introduced this code. To some extent, this whole discussion is not unlike complaining about missing toes after purchasing, loading, and firing a footgun, that had FOOTGUN printed on it in large block letters. [image] Benny: guard against that beyond proofreading code at 100% efficiency Again, I am not necessarily disagreeing — if we had a good technical solution here, it would make sense to apply it. Just want to point out that this is a relatively benign bug, because it can be easily tested for ex ante (@assert isdefined(SomeModule, :internals_I_used)), and caught by CI, if it is nevertheless missed, things break immediately and visibly, instead of some silent error that corrupted something and you discover a year later, it can be tracked down super-quickly (top of the stack trace). Unfortunately, 99%+ of bugs are nastier than this, because of one reason or another. This is why people do use internals from other modules in Julia as a workaround, in an admittedly rather informal way, and also why there is no great pressure to fix this — it is relatively innocuous as bugs go.

[image] Tamas_Papp: To some extent, this whole discussion is not unlike complaining about missing toes after purchasing, loading, and firing a footgun, that had FOOTGUN printed on it in large block letters. @Tamas_Papp as already mentioned, it’s a generic discussion about methodology and the general way of doing things. The issues I raised stand, regardless of the exact specific of this incident. I would appreciate it if you’d keep the discussion at technical topics and abstain from comments about people.

Proposed breaking changes to the language’s design aside, what does Base.modules_warned_for even do? The most I could figure out is Base.modules_warned_for == Set{Base.PkgId}(). Any chance the removed code is simple enough to be repurposed for your package’s own internal code? Seems a bit like plagiarism but maybe this is fair game for internal code? Just seems like a faster option than contributing to the language standard.

It does seem like an odd internal to depend on. It was there as a state tracker to avoid warning about broken package resolves multiple times in some code that was put in place to ween users onto routinely using environments. It didn’t actually work in a lot of cases due to precompilation warnings happening in nested processes, thus the warning state didn’t propagate. I’m genuinely interested to see why it’s needed, but perhaps that discussion could move to an issue on the package it’s needed in. Feel free to tag me, given it was my PR that removed it.

Base.modules_warned_for silently removed in 1.8

General Usage

ericphanson June 9, 2022, 12:25pm 97

You can also add a PkgEval badge to your readme if you want: ANN: Nanosoldier package evaluation -- with badges!

Topic		Replies	Views
A kind of "two language problem" in Julia Ecosystem General Usage	53	4593	May 30, 2026
Implementation Hiding Proposal Internals & Design proposal	19	2053	May 10, 2018
Forward compatibility and stability of Julia vs. Packages General Usage	97	5115	August 27, 2023
I find it hard to develop in Julia Internals & Design	71	6610	February 13, 2026
Private states in Julia modules General Usage question , package	24	8222	November 20, 2024

Base.modules_warned_for silently removed in 1.8

Related topics