New package: SiennaPRASInterface v0.1.0

[JuliaRegistrator]

• Registering package: SiennaPRASInterface
• Repository: https://github.com/NREL-Sienna/SiennaPRASInterface.jl
• Created by: @jd-lara
• Version: v0.1.0
• Commit: 77b86038b7ba8cdb44ae8748416e4ca5c2de5fee
• Reviewed by: @jd-lara
• Reference: NREL-Sienna/SiennaPRASInterface.jl@77b8603#commitcomment-149530178
• Description: Interface to PRAS.jl maintained by Sienna\Ops

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

[noblock] Do you just want to wait out the three days, or should we see if this can be merged sooner? Normally, I’m pretty opposed to early merges or to bothering the maintainers when not absolutely necessary. But in this case, I bear some responsibility for the delay, and it should be a very clear-cut case, so I would fully support a manual merge if waiting would cause any problems for you.

I don’t have merge permissions myself , so unfortunately I can’t just do it myself.

[GordStephen]

Maintainer of https://github.com/NREL/PRAS here. It sounds like we have some internal discussions to work through and would prefer if this wasn’t registered immediately. For what it’s worth we’re entirely open to registering PRAS, but have known for a while that getting the package name through would be a challenge.

[goerz]

Personally, I'm not actually that opposed to acronyms in package names. I don't know how much consensus there is on this (@gdalle seems more sensitive to this), but IMO pronounceable acronyms (which PRAS is) should often be fine. For longer acronyms that involve some kind of pun or double as a word or name (which PRAS doesn't), I'd even say they can make good package names. Basically, the capitalization of a package should have no impact on whether it can be used. If we'd be okay with Pras.jl, we should also be fine with PRAS.jl.

There's certainly a strong bias for "long, descriptive" package names ("err on the side of clarity"), but that doesn't mean that those are the only type of package names that are acceptable. I would argue that pronounceable acronyms can fall in the category of "less systematic names" that also contains hugely popular packages like Makie and JuMP.

The point of the all-caps and minimum length checks is basically to prevent the proliferation of a bunch of random 3 and 4 letter acronyms that are the pinnacle of "jargon".

There's also other considerations for short package names, like how fully developed a proposed package is. If it already has a community behind it, has good documentation, multiple contributors, that makes a much better case for exceptions to the naming guidelines. It seems to me that PRAS is on a pretty good path there, so that speaks in its favor.

Another issue that maybe we haven't fully come to grips with is that there are communities where often C++ has been dominant, with a culture of acronyms. The high energy physics community has been one such example, and possibly, PRAS also falls into that category. The issue is then confounded by the community aspects of the Julia ecosystem, where registrations are reviewed and may receive pushback. I believe this community aspect is an important component of Julia, and at least to some extent, stems from the interoperability of packages deriving from multiple dispatch. More than in other languages, we want a cohesive ecosystem of packages that work well together and follow similar conventions. I understand this can be alienating to users coming from other languages or communities with different naming conventions. In C++, there is no equivalent to the General registry, and PyPI has no moderation whatsoever, and really no other language I'm aware of has quite the same DescriptiveCamelCase approach to package names.

Julia as a language has a lot to offer to those communities. So, we will have to find a way to make sure not to alienate these users, without giving up on the unique character of the General registry, and making it a free-for-all of acronyms. That's not an easy problem to solve. We can't always tell the background of people submitting to the general registry, and there's not always the bandwidth to engage at length, at a personal level. Still, finding the most effective communication strategies is definitely something that requires more reflection, and is something that I try to improve upon (and have definitely failed at on some past occasions).

All of this is to say that I think there's a pretty good chance that PRAS could be registered under its existing name. Especially since I'm not even sure what a hypothetical alternative name might be. As a "triage member" I can't override the all-caps rule nor the minimum length rule, so I can't make any promises. The registration would have to be merged by a full maintainer. I wouldn't be too pessimistic about it, though.

[noblock]

[gdalle]

[noblock] I would prefer a longer, more descriptive name but I won't veto PRAS since it seems to come from a trustworthy place

[GordStephen]

Thanks @goerz and @gdalle - if that's the case we'll submit PRAS for registration. I've just submitted its only unregistered dependency (which is hopefully less controversially-named) in #120355

[jd-lara]

@goerz we can close this and use #121757 instead.