Naming recipes/packages

[stemann]

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

• New recipe: MEOS Yggdrasil#9453 (comment)
• [Xorriso] add builder Yggdrasil#10956 (comment)
• Create build_tarballs.jl for norMD Yggdrasil#11075 (comment)

The BinaryBuilder docs, read:

... It should be the name of the upstream package, not for example that of a specific library or executable provided by it, even though they may coincide. The case of the name should match that of the upstream package. Note that the name should be a valid Julia identifier, so it has meet some requirements, among which:

• it cannot start with a number,
• it cannot have spaces, dashes, or dots in the name. You can use underscores to replace them.

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 than xorriso. Or choosing names which do not include field-specific jargon, MobilityEngineOpenSource rather than MEOS.

Should we add something to the Name section in the docs?

---

Edit (2025-05-02 08:30 UTC - after some sharpening of my argument):

My two arguments:

• When, and only when, the source project does not specify casing, it might be preferable to choose UpperCamelCase.
• When, and only when, the source project name is only known in a certain field, i.e., not known in general, and the name might clash with other, more common projects (yet to be registered), it might be preferable to disambiguate using the standard Julia package naming standards.

[giordano]

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.

They'd pass registration no problem. That concern is unwarranted.

[stemann]

But JLL packages end up in the same namespace as regular Julia packages (except for the _jll suffix), so why make an exception? (except for the obvious mainstream cases, e.g. for a completely standard CLI tool where people would be surprised by e.g. UpperCamelCase)

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.

[stemann]

... and I'm arguing for not filling up the shared namespace (package names) with field-specific jargon.

[stemann]

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)

[diegozea]

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.

[stemann]

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 abseil_cpp should have been named Abseil - the repo. is named abseil-cpp, but the library authors clearly refer to it as "the Abseil C++ library". It's an example of naming that could perhaps be remedied by highlighting a preference for UpperCamelCase.

[StefanKarpinski]

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.

[StefanKarpinski]

But JLL packages end up in the same namespace as regular Julia packages (except for the _jll suffix), so why make an exception?

So, effectively not in the same namespace at all? Prefixing or suffixing with a string like _jll is a time honored way of doing name spacing on the cheap. But also: why does it matter that they're in the same namespace? We could have a separate JLLs registry—would that change the situation in any meaningful way?

[stemann]

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.

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.

But JLL packages end up in the same namespace as regular Julia packages (except for the _jll suffix), so why make an exception?

So, effectively not in the same namespace at all? Prefixing or suffixing with a string like _jll is a time honored way of doing name spacing on the cheap. But also: why does it matter that they're in the same namespace? We could have a separate JLLs registry—would that change the situation in any meaningful way?

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.

[stemann]

My two arguments (sorry if I'm repeating myself):

• When, and only when, the source project does not specify casing, it might be preferable to choose UpperCamelCase.
• When, and only when, the source project is from a sub-community with their own namespace, and the name might clash with other, more common projects (yet to be registered), it might be preferable to disambiguate using the standard Julia package naming standards.

[stemann]

Regarding the norMD example, please see normD (not so relevant) and normd (more relevant) mentioned in JuliaPackaging/Yggdrasil#11075 (comment)

[diegozea]

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.

[stemann]

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.

[stemann]

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.

Yes - the suggested additions to the naming guidelines are purely for the edge cases - they would rarely apply.

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.

Completely agree - no doubt about this - we should not discriminate certain fields (but also not the common ground while catering for one field).