-
Notifications
You must be signed in to change notification settings - Fork 105
Naming recipes/packages #1379
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
Comments
They'd pass registration no problem. That concern is unwarranted. |
But JLL packages end up in the same namespace as regular Julia packages (except for the I'm not arguing for forbidding lower-case JLL names, just preferring UpperCamelCase when upstream does not specify casing, e.g., a CLI tool where casing might've been out of the question from the start. |
... and I'm arguing for not filling up the shared namespace (package names) with field-specific jargon. |
I just saw your comment in the norMD PR: I did not know (or rather, I think I had forgotten) that JLL package names are not checked when running registration checks (AutoMerge). All the more reason to be extra prudent when naming JLL recipes/packages! (which I think we (i.e., you 😊) generally are) |
I’d like to offer a different perspective. I would argue the opposite: JLL package names should remain as close as possible to the name of the software or software suite they provide, including casing, as defined by the original authors and recognized within their community. This enhances recognition and discoverability. Exceptions should only be made when a naming conflict exists or is likely to arise. Otherwise, preserving the original name better reflects the upstream identity, which may follow naming conventions outside those of the Julia ecosystem. For this reason, I support the current documentation and existing approach. |
I do not argue for choosing a name different from the upstream source (software / software suite). But, when the executable/library in question is only relevant for a certain sub-community, and the authors decided to use a name so short, that there is an obvious chance of name clashes, it should be considered to disambiguate it. On a related vein (though a bit off-topic), I would also argue that |
When we first started registering JLLs I advocated strongly for matching the naming of the upstream library or program exactly because that is the only choice that doesn't lead to arbitrary and inconsistent human decisions about which things to capitalize and how. Also, we don't really care about capitalization of JLLs from an aesthetic perspective because loading a JLL directly is (a) rare and (b) it's ok for it to look non-native since it is non-native. That recommendation did not prevail, and as a result we have a predictably chaotic mess of capitalization choices for JLLs. Anyway, don't matter that much, but that's my position: we should NOT apply Julia package naming standards to JLLs and on the contrary we should exactly match the name and capitalization of the thing being wrapped. |
So, effectively not in the same namespace at all? Prefixing or suffixing with a string like |
That sounds very sane. ... and I would also say, from my naïve perspective, that except for (all) the exceptions, this is also mostly where we are.
True, they are in separate namespaces, but whenever anyone tab-completes from the Pkg REPL, they are kind of in the same namespace. And yes, it doesn't really matter whether or not they are in the same namespace / registry. Edit: Moved my arguments to a separate comment. |
My two arguments (sorry if I'm repeating myself):
|
Regarding the |
I’d like to respectfully disagree with the second point. As someone working in bioinformatics, I felt a bit uncomfortable with the idea of labeling certain fields—like mine—as “sub-communities” whose naming conventions are seen as less important or secondary to others. It comes across as dismissive, even if unintentionally so. In practice, most of the packages wrapped as JLLs already come with well-established names from their source projects, so the idea of defaulting to the Julia naming standard rarely applies. While I support using consistent naming when no upstream convention exists, suggesting disambiguation only for certain fields feels unnecessarily opinionated and may discourage participation from communities that are already underrepresented in the Julia ecosystem. Personally, I would love to see more bioinformatics tools packaged as JLLs, and I’d prefer that they not be treated differently in a way that might alienate contributors or users from those domains. |
I'm sorry if "sub-communities" came across as dismissive - that was certainly not the intent. My point of view (coming from Computer Science) is that Julia is a general purpose programming language - kind of contrary to the often (vocally) voiced "we are all scientists/engineers" - indicating Julia is only used for scientific/technical computing. So if something is not common in the world of general purpose programming, e.g., only known to members of a certain scientific field, I think disambiguation might apply. |
Yes - the suggested additions to the naming guidelines are purely for the edge cases - they would rarely apply.
Completely agree - no doubt about this - we should not discriminate certain fields (but also not the common ground while catering for one field). |
Uh oh!
There was an error while loading. Please reload this page.
In a couple of recent Yggdrasil PRs I've been involved with, naming recipes/packages "has come up" (I may have assisted in this part).
E.g.,
The BinaryBuilder docs, read:
I find myself arguing for choosing names which would pass registration as any other Julia package in the Julia General registry, e.g. opting for an UpperCamelCase name in case of ambiguity wrt. the upstream naming, e.g.,
Xorriso
rather thanxorriso
. Or choosing names which do not include field-specific jargon,MobilityEngineOpenSource
rather thanMEOS
.Should we add something to the Name section in the docs?
Edit (2025-05-02 08:30 UTC - after some sharpening of my argument):
The text was updated successfully, but these errors were encountered: