Package Naming Guidelines
John Myles White
So here’s an attempt to name a few tentative rules:
(1) Don't use an acronym unless there is no possibility of confusion.
For example,
* It's ok to say USA if you're talking about the USA
* It's not ok to say PMA, even if you're talking about positive mental attitude
(2) Package names should be plural, especially if you want to define a type in your package with a similar name.
For example,
* DataFrames provides the DataFrame type
* BloomFilters provides the BloomFilter type
(3) Err on the side of clarity, even if clarity seems long-winded to you.
* If you’re aiming to write the definitive Julia tool for data visualization, DataVisualization is a sane name. DataViz should also work. But DTVIZ is a bad name.
(4) Non-informative names make sense for projects that can’t be the “unique source of truth” for a certain set of problems. There are many ways to fit neural nets, so no package should be called neural nets. On the flip side, there’s no reason that Julia needs many competing implementations of bubble sort. So all sorting algorithms belong in the SortingAlgorithms package.
— John
Joey Huchette
I agree with all your points. In particular w.r.t. (4), I’m a big fan of quirkier, unique names a la Mocha.jl or Mamba.jl (to pick just one letter of the alphabet).
I think we also need to discuss naming conventions for wrapper packages. Libraries with distinct at least fairly google-able names (e.g. CPLEX, Gurobi) can probably be named CPLEX.jl and Gurobi.jl without second thought, since this won’t really violate (1). This gets a little bit more confusing with less creative names, like CSDP, where there’s maybe a greater chance of confusion for the user, and for name clashes. Perhaps we should stipulate a uniform suffix for wrapper libraries (CPLEXLink was suggested at one point, for example), but that’s definitely less aesthetically pleasing, and maybe unnecessary.
Stefan Karpinski
Waldir Pimenta
Jiahao Chen
David Anthoff
Here is another idea on package names:
The current policies for package names that live in “root” just stay, i.e. if you want to register a package that is just one word, you have to abide by the rules the Julia devs come up with and argue with them if they disagree with your naming choice. This is the part of the package namespace that is “policed” (in the best sense of the word).
In addition one can register packages with a name of the format “Owner.Packagename”. In this case ONLY the Owner name is subject to rules, but one is free to use whatever one wants for the Packagename part. The Owner part could be the family/given name or the name of an organization, i.e. something where a real name exists in the real world already. But then everything to the right of Owner is free game, not subject to central oversight and rules. This is the model the is used for .Net assembly names and I believe it has worked very well for a very large and chaotic scene of software.
The main benefit of such an arrangement would be that it bridges to conflicting goals: on one hand we clearly want nice names for the core packages, and have some control over that space. At the same time that model really won’t scale, and there are many instances where the naming choice of a package will be primarily driven by the conventions and goals of a specific subject area/academic discipline/something else rather than a consideration of how a name flies with the Julia crowd.
Cheers,
David
PS: I guess another alternative would be to evolve the package system such that one can take dependencies on unregistered packages in a REQUIRE file etc, thereby largely eliminating the need to register a package and just relying on the git repo namespace system. But that might have really bad performance implications, right?
Tony Kelman
David Anthoff
Generally I like the “dependency on unregistered packages URLs” by far the best. I think the ideal situation would be that Pkg.add() just accepts both short names and URLs, and that REQUIRE files can also have URLs and short names in them.
