New package: MicroMag v0.3.1

[JuliaRegistrator]

• Registering package: MicroMag
• Repository: https://github.com/ww1g11/MicroMag.jl
• Created by: @ww1g11
• Version: v0.3.1
• Commit: d52eda69f1a7685f0b0680d14b0bd40c13b49232
• Reviewed by: @ww1g11
• Reference: @JuliaRegistrator register MagneticSimulation/MicroMagnetic.jl#6 (comment)

[gdalle]

The problem is the same as with your previous two registrations. Even if the automated checks pass, anyone from the community (like me) can object to a package registration. In this case, the name is once again too short and not precise enough. What about "MicromagneticSimulations"?

See also:

• New package: JuMag v0.3.0 #105307
• New package: NuMag v0.3.1 #107227

[github-actions]

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

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines

---

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. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[gdalle]

Sorry for what must feel like harassment at this point ^^ But the package namespace is limited, and it doesn't cost much to be more specific

[ww1g11]

[noblock] I think MicroMag is better than MicromagneticSimulations, suppose we want to use a function from the package, it would be inconvenient to use MicromagneticSimulations.fun_name.

[gdalle]

I think MicroMag is better than MicromagneticSimulations, suppose we want to use a function from the package, it would be inconvenient to use MicromagneticSimulations.fun_name.

You have plenty of options to avoid this, here are a few:

using MicromagneticSimulations  # you can now call every exported name
using MicromagneticSimulations: fun_name  # you can now call fun_name
import MicromagneticSimulations as MS  # you can now call MS.fun_name

[ww1g11]

[noblock] Thanks for the suggestion, but I still think MicroMag is better.

[gdalle]

@goerz care to weigh in?

[goerz]

I would strongly prefer MicromagneticSimulations to MicroMag. Shortness of a package name is not something I would generally put any weight on, as the full package name is not something that needs to be typed often. @gdalle already demonstrated all the ways in which members of the package would be used. I'd always optimize for clarity when choosing a package name. So, my 2 cents are to recommend for @ww1g11 to reconsider the package name.

[nilshg]

I think we're often going overboard with ExtremelyLongAndDetailedPackageName in Julia, but seeing that Mag just isn't a common abbreviation for magnetic but actually a common abbreviation for magazine I think just expanding that might be a good compromise?

@ww1g11 the others and already mentioned the sparsity of the namespace resource but from an author's perspective it's also useful to have a descriptive name for potential users and contributors to discover your package.

[rafaqz]

MicroMagnetic.jl or similar seems like a good enough name to me.

[ww1g11]

@nilshg Thanks for the suggestions, for me MicroMag.jl is not an ideal name, so MicroMagnetic.jl is okay for me (I still think this kind of name is worse than JuMag.jl and NuMag.jl).

@gdalle @goerz
However, I would like to say that a long and descriptive name is not always a good strategy, sometimes this kind of name is too big. There could be many packages in the same area but only one descriptive name. For example, for the packages using finite element method, there is only one FEM.jl or FiniteElementMethod.jl, in such situations, actually one should choose this name carefully unless this package is expected to be better than similar packages. Suppose someone developed a package related to machine learning and the long and descriptive strategy will suggest the package name to be MachineLearning.jl, but how do you know this name is suitable for the package? Similarly, if I chose MicromagneticSimulations.jl, how should others name their micromagnetic packages?

In terms of limit space of package namespace, I believe it's not just Julia that has this problem, so how pip and debian solve this problem? Long and descriptive naming is not the only solution.

PS: I have measured the Damerau-Levenshtein distance between NuMag and NUMA, which gives 3. Since Julia is case-sensitive, why the automatic checking use the lower cases? I believe most people will not think NuMag is too close to NUMA.

[gdalle]

Suppose someone developed a package related to machine learning and the long and descriptive strategy will suggest the package name to be MachineLearning.jl

For such a generic case, the people watching the general registry (like @goerz and I) would probably suggest either of the following options:

• Try to merge the functionality into one of the big existing ecosystems, like MLJ.jl or Flux.jl
• Pick a less generic name, like MachineLearningUtilities.jl or MachineLearningForBiology.jl
• Avoid registering altogether, and use a local registry instead

Similarly, if I chose MicromagneticSimulations.jl, how should others name their micromagnetic packages?

I am not qualified enough to say whether your package will be the "reference" package in micromagnetic simulations. However, I don't think this doubt is an argument for naming it MicroMag.jl either, because you claim generality both over the topic of magnetism and the topic of magazines ;)

how pip and debian solve this problem

I have no clue.

---

You obviously feel very strongly about this, and I don't have infinite energy to spend debating it. MicroMagnetic.jl is not ideal but it's much better and more explicit, so I suggest you register your package under that name.

[ww1g11]

I will change the package name to MicroMagnetic.jl, but I believe that the descriptive naming will eventually become problematic because it significantly reduces the number of available names.

[ww1g11]

Please close this PR since the package name is changed #107408

[goerz]

However, I would like to say that a long and descriptive name is not always a good strategy, sometimes this kind of name is too big.

There seems to be a little bit of a confusion between "descriptive" and "general".

Suppose someone developed a package related to machine learning and the long and descriptive strategy will suggest the package name to be MachineLearning.jl

No, "MachineLearning" would not be an appropriate name for a package just related to machine learning. The package name (if it follows the "descriptive" route) should describe which aspect of machine learning the package covers, as narrowly as possible. And yes, this may be a long name. But "long" is not a problem. Actually, registering a package with the name "MachineLearning" would be quite difficult: it would have to cover the entire field of machine learning (the way DifferentialEquations covers the entire world of differential equation solving). I would also insist that it is fairly well-developed at the time of registration, and has a team of maintainers with long-term funding that guarantees continuing maintenance and the resources to develop a package with such a wide scope. Similarly, (a little less so) for something like "FiniteElementMethods.jl": Registering such a package implies taking on the responsibility to maintain it appropriately for a wide scope. Anyone working in finite elements should generally be contributing to that package, not starting their own package. Of course, if they have a package with a narrower scope, that can still be an independent package (with a more specific name). Or, if it's a general framework just with a different philosophy, often "less systematic" names are a good way to go. Like how I'm maintaining the very general QuantumControl.jl, but there is also Piccolo.jl that covers a different approach to quantum control.

The one thing we want to avoid is abbreviations for the sake of shortness. Shortness is not a goal in Julia package naming. And, MicroMag and MicroMagnetic are the same package name, so these kinds of variations are not okay to differentiate packages in a crowded name space. For example, MicroBio would have decent chances of being registered (since "Bio" is an extremely recognizable abbreviation), but once it exists, I would definitely block MicroBiology as being "taken".

In terms of limit space of package namespace, I believe it's not just Julia that has this problem, so how pip and debian solve this problem?

PyPI is almost completely unregulated, so package names are used up on a first-come-first-serve basis. There is no review of whether package names are appropriate or whether they are too similar to existing packages, or even whether there is malicious typo-squatting. That's now how we do things in Julia.

It is also important to note that many languages have a culture of "short" package names. This especially includes compiled languages because these are run from the command line. Same for Debian packages: these names need to be short (which is actually a much bigger constraint than in Julia: there are far fewer good short names than good long names). Also, Debian has a maintainer team that deals with naming conflicts by renaming packages as they see fit.

Long and descriptive naming is not the only solution

There's always the "less systematic names" (Makie, Zygote, etc.), which I'm actually a big fan of. But they require more creativity. IMO, these can also include pronounceable acronyms – we shouldn't have a strict rule against all-caps names.

I believe that the descriptive naming will eventually become problematic because it significantly reduces the number of available names.

This is a feature, not a bug. We would not want a dozen competing packages with the same scope and with names that are small variations of each other (as Python might have). It's much better if there is one authoritative package for a specific problem domain. Of course, that puts responsibilities of the maintainer, and is partly also why we have a review for registrations in General. Julia has a much stronger community aspect than any other language I've worked with. Up to the point where if the maintainer of package with a large scope were to disappear, the registry maintainers could appoint an authoritative fork of the package. We also encourage the development of "large" packages in organizations (with multiple owners), not personal accounts. In my opinion, this bodes well for the longevity of the Julia ecosystem.

Similarly, if I chose MicromagneticSimulations.jl, how should others name their micromagnetic packages?

Like I said, whether you name it MicroMag or MicromagneticSimulations.jl has little to do with this – except that "Simulations" makes it more specific. So now there could be another package, e.g., "MicromagneticModels". But if someone wanted to work on micromagnetic simulations, they should be contributing to your existing packages.

PS: I have measured the Damerau-Levenshtein distance between NuMag and NUMA, which gives 3. Since Julia is case-sensitive, why the automatic checking use the lower cases? I believe most people will not think NuMag is too close to NUMA.

The "name similarity check" is 90% false positives. It's just that we haven't come up with any better automatic check, so this just puts a pause on the registration until a maintainer can review it. Most of the time, the name similarities get overridden without any discussion. And yes, NuMag is not something that would be confused with NUMA. So that name similarity is absolutely not the issue here.