Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support public keyword in Julia v1.11 #260

Open
gdalle opened this issue Jan 19, 2024 · 2 comments
Open

Support public keyword in Julia v1.11 #260

gdalle opened this issue Jan 19, 2024 · 2 comments
Labels

Comments

@gdalle
Copy link
Contributor

gdalle commented Jan 19, 2024

See this comment on Discourse:

In the future, one could imagine QA tools that check whether a package uses any non-public symbols from another package.

Sounds like a job for Aqua? Not urgent of course but opening the issue to keep track

@mnemnion
Copy link

I don't think this is a good general feature for a code quality tool.

Looking through the list of what Aqua tests, everything is a real problem, latent or otherwise. Using a non-public part of someone else's package is a hypothetical problem: some future minor release might break that feature. Or that might not ever happen.

When I use internals, which does happen, I write a test which verifies the behavior I need from that function. This means if an upgrade breaks what I rely on, the test suite will tell me right away, and I can decide what to do about it.

This isn't naughty behavior (type piracy) a lurking problem (method ambiguity, compat boundaries), or a mistake (undefined exports). It's just using code, and that code has the same guarantees as the (many!) packages which aren't 1.0: none. I don't need Aqua shaking its finger at me over it.

Sure, I could turn it off, and would. But this gets public entirely backward. It's a self-imposed obligation of consistent behavior for some part of a package. It doesn't mean "hands off unless I say so".

@gdalle
Copy link
Contributor Author

gdalle commented Nov 24, 2024

Looking through the list of what Aqua tests, everything is a real problem, latent or otherwise. Using a non-public part of someone else's package is a hypothetical problem: some future minor release might break that feature. Or that might not ever happen.

You could also consider this a latent problem waiting to break out. I have had very real problems with dependency internals changing.

When I use internals, which does happen, I write a test which verifies the behavior I need from that function. This means if an upgrade breaks what I rely on, the test suite will tell me right away, and I can decide what to do about it.

That's of course a very good practice, but Aqua is here to enforce best practices, including among people who may not abide by them in the first place. I think you're the exception rather than the rule.

Sure, I could turn it off, and would. But this gets public entirely backward. It's a self-imposed obligation of consistent behavior for some part of a package. It doesn't mean "hands off unless I say so".

I think it does actually say "hands off unless I say so, except for experts users". But Aqua is most helpful for non-experts.

Besides, Aqua disapproving of type piracy is not so different than Aqua warning about use of private symbols.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants