Package naming guidelines

Community
21

I’d say only abbreviations that wrap packages in other languages. So FFTW.jl is fine, and so is CUDA.jl, GLFW.jl, LLVM.jl,etc.

3 Likes
22

I think that ‘FFT’ is one abbreviation that is actually (far) more well-known than what it abbreviates. I’m pretty sure more people have heard about ‘the FFT’ than about ‘the Fast Fourier Transform’.

Long names are not nice, and it’s especially annoying since you cannot do

using SingularValueDecomposition as SVD

Also, @dlfivefifty’s examples: How many would recognize ComputeUnifiedDeviceArchitecture.jl, or LowLevelVirtualMachine.jl ?

3 Likes
23

In cases where the abbreviation is much more well-known than the long form I guess that’s often better too. GLM is another example. Though I do find it very nice that you can usually glean what a package does by it’s name even if you’re not an expert in the field. BTW you can do import SingularValueDecomposition; const SVD = SingularValueDecomposition, arguably not as nice, but still.

1 Like
24
1 Like
25

Yeah, but that’s even longer! :wink:

1 Like
26

ImportMacros are nice. It would be great if it worked like this without the extra dependency.

2 Likes
27

The usefulness of an as keyword is much less in Julia than Python since usually you don’t need to refer to the module name again after calling using

1 Like
28

Consider import, too.

29

import usually happens inside a package, in which case the burden of typing const SVD = is minimal.

I didn’t say it’s not useful, just no where near as important as in Python.

30

I think import is going to be deprecated in favor of using. I don’t have a reference right now but I’m pretty sure I read it on some GitHub discussion

32

Found it:
https://github.com/JuliaLang/julia/issues/8000
No decision taken, though.

2 Likes
33

In the future we could have big codebase and backward compatibility will be important too.

With something like:

using LongNameOfShiny
using LongNameOfUseful
init()

we have to be afraid of presence of init() in both packages after every upgrade of packages.

This could be good convenience to write long time supported codes:

using LongNameOfShiny as Shiny
using LongNameOfUseful
Shiny.init()
2 Likes
34

I always find the do keyword confusing. Seems like that could be as instead, though I’m very unsure about how that works.

35

How about allowing abbreviations that are very well known in the disciplines in which they’re used, and include documentation that spells out all accepted abbreviations, so that it is easy to obtain the spelled out version?

1 Like
36

I suppose another option (I’m not sure I’m in favor of it) is to require the long version as the Package name, but allow a short alias (typically the acronyms that are ambiguous).

In other words, Pkg.add("FastestFourierTransformWest") would return the same package as Pkg.add("FFTW").

Potential Benefits

  1. Users outside of some field may recognize some overlap with a package that otherwise uses unknown abbreviations, leading to improved network effects for Julians.
  2. The short form can be seen the first time the documentaiton is accessed.
  3. No breaking changes for the naming packages as all existing packages fit into either the long or short form.

Downsides

  1. Names get used up twice as quickly (however, these names should be from the orthogonal long and short domains, so this is not really a big issue).
  2. Modifications are required (I suppose at least to Pkg and METADATA) to support the package aliasing.
6 Likes
37

Trying to solve the discoverability problem with package names is fraught. Instead we should create and impose some semi-standardized tagging system: say a file KEYWORDS, with a list of standardized keywords to pick from but also allowing free-form ones. Then we can be free to choose package names we like (within reason).

5 Likes
38

In a post copy-paste word, long length is hardly an inconvenience. Unclarity is.

39

I strongly disagree with this. Copy-pasting is super annoying, I don’t want to do it every time I need to enter some text.

1 Like
40

no, importall is.

41

If the discoverability of packages is the biggest concern here, then the solution probably will not come from changing the namings of the packages. Instead, needed is some sort of “tagging” system, which allows you to browse packages by keywords and tags, allowing users to filter by topics and categories to find what they need

The keywords file should also be on github, so it can be extended as the ecosystem evolves.

2 Likes