Thanks. I think it’s worth that we as a community explore that space and see where it really brings a benefit. There are advantages to explore this with an implementation in Core (no type piracy) and there are advantages to do this with a (registered) package (can be archived if no longer used or superseded). But anyway, it seems to be an interesting degree of freedom to have opening up a new corner in the design space.
It’d be cool if there was a better way to achieve that.
We currently have two ideas as far as i know:
Moving it into Base/Core to avoid the type piracy problem
Having each module being a separate type
From a theoretical point of view I currently prefer the second option, but we’d need a complete list of the implications this would have and see whether there are other options. But having multiple strong use cases first might be the better order.
Indeed, they are … controversial (seems to be the general theme of this discussion). Some languages like Java use them due to similar reasons. However, I agree that a lower-case command line interface app name might make more sense.
But even with a lower-case CLI, this still keeps the module name identical to the Julia interface using CallableModules.jl. It circles again around the point raised above: Although having an interesting design space, we might lack use cases which are convincing enough.
Thanks for everyone taking part in the discussion. I appreciate this and I think it brought up interesting aspects.
I feel like the original intention of this thread has run its course: The package currently is too controversial for being registered, so I will not do this at the moment. This is fine, as the two main intentions of open-sourcing it are
everyone can use it – for this it does not need to be registered
avoiding a single point of failure by moving it to a Github community – this does not seem to happen independent of it being registered
My goal is not to cause controversy, but to improve the Julia ecosystem. Therefore, I hope this allows cooling down the discussion a bit so that we can focus on the pros and cons of different interesting aspects which were brought up during the discussion.
Although never explicitly stated, I have the feeling that we need to avoid the following trap:
Base/Core wanting enough exposure in a package first before committing to a new feature.
The general registry declining the package containing that feature, because the package contains type piracy, as the feature is not implemented in Base/Core, but in a package.
The unregistered package not getting enough exposure for the feature to be considered adding it to Base/Core.
goto 1
Although each of the steps is totally plausible in isolation, the combination of all steps does not seem to be intended.
Feel free to continue the discussion until the mods think it has also run its course, but I consider the original intention of this topic to be solved.
The problem with piracy is that, unlike some other examples of suboptimal design, it is not constrained just to the package at fault. Piracy potentially breaks any loaded code. So any package can break because an unrelated package does piracy.
IMO if the General registry allows piracy, at the very least the package manager should warn the user about piracy before installing the package that does piracy. When known.
a package that segfaults your process would also “break” other loaded code (in the sense that nothing runs anymore lol), but the General registry can’t forbid the use of @inbounds or unsafe_wrap
True, type piracy is similar in this regard to UB. What matters is that the type piracy here is intentional. The proposed package is kinda pure type piracy, that is, the main purpose of the proposed package is type piracy.
The difference is that UB (or type piracy, for that matter) that is a mere bug, such as out of bounds indexing with @inbounds, can be fixed in a patch release of the package in question.
In contrast, there is no fixing the package proposed here.
Except for the tenuous possibility that we can somehow ensure both of these:
JuliaLang/julia v1 will never make use of the method signature in question.
The General registry will never add any other package that makes use of the method signature in question.
Speculative: I am not sure but I feel like @goerz is the principal maintainer of the General registry. And I suppose he does it as a volunteer. So, assuming we wanted to ensure no such package gets registered ever (again), someone would have to step up and commit to review every package registration ever forever. This is not realistic. Which is presumably one of the reasons why @goerz is opposing the registration.
However, at that point a PR to JuliaLang/julia would be simpler anyway.
No… I am far from the “principal” maintainer of the General registry; and I was only a triage member until very recently. I might be particularly active in superficially reviewing pending registrations, hence maybe the perception. But I certainly don’t have any kind of special authority over package registrations, and will usually defer to more senior registry maintainers when in doubt.
We have very few “blanket rules”, and “type piracy” in particular is a complicated issue. Although, personally, I’m very concerned about type piracy, I’m only advocating that type piracy should prevent auto-merge, so that the situation can be discussed in more detail. And even that is speculative.
A lot of checks can be automated, and we should do more on that front. But beyond that: Any member of the community is encouraged to monitor and review registrations. Triage members have slightly elevated permissions in that they can override certain automerge checks like name similarities, and full maintainers have even more elevated permisions, in that they can manually merge packages. But the system is still built on good-faith-discussion and consensus, and we welcome all comments about concerns with new registrations. I certainly wouldn’t mind if we had a larger group of people who reviewed registrations that are within their sphere of interest. Even beyond superficial things like package naming and the presence of tests or documentation. Keep it constructive, though: the goal is to help people to register high quality packages, and to have a cohesive and rich ecosystem, not to gate-keep.
For this to be analogous to type piracy it would need to segfault just from being loaded, which is of course possible, but maybe not that likely in practice. And if it did so consistently it would fail the automerge checks.
Because of the infix operator -, many languages can’t use hyphens to separate words in a name, at least not in a way that’s nice to read and write e.g. parsing var"verb-noun" to Symbol("verb-noun"). Hyphens aren’t the only conventional word separator, but people won’t compromise their conventions for Julia’s parser no matter how justified and willing we are to buck our own naming conventions.
Please don’t let these feelings stop you from helping out! The more eyes we have on package registration the better. Some problems are hard to spot, and you might miss them or misdiagnose them, but that’s fine, it’s better than if nobody was watching.
The worst you can do is flag something as problematic that wasn’t actually problematic, and then the registry maintainers can just manually overrule whatever objection you had. That’s totally fine and normal.
If we only rely on vetrans to watch package registrations, soon we won’t have anyone watching them.
