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

New package: GRSuite v0.0.1 #122621

Conversation

JuliaRegistrator
Copy link
Contributor

UUID: 090ec698-01a0-4de4-b9a9-b0520fa6fd58
Repo: https://github.com/AuroraDysis/GRSuite.jl.git
Tree: ec0f7b033bb76c045b13c77f6fa744d4a3859aab

Registrator tree SHA: 17aec322677d9b81cdd6b9b9236b09a3f1374c6a
Copy link
Contributor

github-actions bot commented Jan 8, 2025

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.

@AuroraDysis
Copy link

[noblock]

I want to use the name GRSuite.jl. Can anyone help me resolve the issue? I don't think it is similar to MLSuite.jl.

@kellertuer
Copy link
Contributor

[noblock]
I feel the name is very unfortunate. There exists GR.jl, which might lead to the impression this is about a Suite for that, especially since GRUtils.jl does exist and does provide utilities for GR(.jl). Also “suite” could be _anything. So the name here is a (not unique) abbreviation together with a noun that provides no further information.

What about

  • GeneralRelativity.jl? Or the other way around: What justifies the “suite” suffix? I think that is not necessary.
  • GeneralRelativityPDEs.jl might also be nice, since for now the name does not indicate that this is about solving PDEs
  • Relativia.jl was proposed on slack as well.

@aplavin
Copy link
Contributor

aplavin commented Jan 9, 2025

IMO the GR/GRUtils conflict is quite strong. That's a very popular package, and also the default Plots backend.

I think the situation of GR.jl, GRSuite.jl, GRUtils.jl, GRTools.jl, etc where half of them are about plotting and half about general relativity isn't optimal and can easily lead to confusion :)
GR.jl is probably a historical artifact, currently General doesn't tend to accept 2-letter names – but it's here to stay.

@JuliaTagBot JuliaTagBot added the AutoMerge: last run blocked by comment PR blocked by one or more comments lacking the string [noblock]. label Jan 9, 2025
@AuroraDysis
Copy link

[noblock]

Hi @aplavin, I won’t repeat the entire discussion here since it’s already quite lengthy in the Slack channel. If you’re interested, please check there.

https://julialang.slack.com/archives/C6M4DQA5P/p1736362206643109

The conflict doesn’t seem significant to me. There might be a better name, but I don’t have time to think of one right now. I’ve already explained in Slack why this name works best and why the alternatives don’t.

Plots.jl is popular, but few users install and use it as a standalone library. Many are even unaware they are using GR.

Apple Inc. attempts to monopolize the common symbol "apple." In my opinion, you are doing similar things.

@kellertuer
Copy link
Contributor

As mentioned earlier, there is a community effort to make package names intuitive – so also not confusing. There are also rules.

It is also not about “monopolizing” anything. Naming should help a user find your package but also to not confuse your package with a different ecosystem. So the name should both transport well what your package provides but also avoid confusing your package with other ecosystems.

Though I think GR.jl predates quite a few of these rules, it does wrap the GR api and hence rule 6 says

  1. Packages that wrap external libraries or programs can be named after those libraries or programs.

And that is what GR does to some extend. It also already exists and is very well established and often used directly indeed. I just saw it turns 10 years today.

Concerning the name here, there are

  1. Avoid jargon. In particular, avoid acronyms unless there is minimal possibility of confusion.

and

  1. Err on the side of clarity, even if clarity seems long-winded to you.

The first one is broken due to the confusion that GRSuite is too close to GRUtils in the sense that one would not be able to tell which one refers to which GR. But it also says avoid acronyms. That is what I also already wrote on slack. There is also
That does not mean packages never have acronyms. Some packages might predate that rule, for some it might have been considered less confusing.
But with GR being used for 10 years already for something different here – there is confusion.

And finally there is also

  1. Avoid naming a package closely to an existing package

So the current name does not follow even 3 of the given naming rules.

From the discussion on slack, since you aim to provide more than the PDE solvers in the future, so something that is meant to takle General Relativity (simulations?) more broadly, I think GeneralRelativity.jl would be a really neat and cool name, but also GeneralRelativitySuite.jl still sounds nice to me.

@AuroraDysis
Copy link

I'm tired of discussing this. Anyway, thanks for the suggestions. I would like to proceed with the name Einstein.jl or EinSuite.jl, if possible.

For Einstein.jl, it shares a somewhat similar goal to EinsteinPy - Making Einstein possible in Python — EinsteinPy, although the functions are a bit different.

For EinSuite.jl: While there are packages like ahwillia/Einsum.jl: Einstein summation notation in Julia and EinExprs, they are still somewhat connected since Einstein introduced this summation for general relativity.

I will wait for comments before renaming everything. I will also post on Slack to attract more attention.

@kellertuer
Copy link
Contributor

[noblock]

Einstein.jl is fine with me as far as I checked for too similar names – we want to avoid packages too close to avoid typos being new packages.
EinSuite.jl is probably fine in naming as well, there I only personally do not like that, can‘t even argue why, just sounds strange. But sure that is subjective, so the name is probably also fine.

I can totally understand that naming is tiring. You committed to a name when you opened this, sure. On the other hand the overall community aims to avoid confusion, when people explore packages. And these names are permanent. So then it is worth carefully finding a solution together. So please do not take that personally and continue your good work on contributing to the Julia community!

And sure checking back on Slack as well is a good idea. I will set mz last post to nonblack when the renaming has happened.

@AuroraDysis
Copy link

I'm not sure how to change the package name within this PR. I opened a new one; please close this in favor of #122822.

@goerz goerz closed this Jan 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants