What’s the best way of distributing a set of closely related functions all of them drawing on a core of helper functions (and each other)?
I think that the only good answer to this is that the functions should go into a package. I would not use the function repository.
You can publish a package now, without waiting for a package repository. An official Wolfram package repository is not a prerequisite (although it would be useful for the community as it would facilitate the adoption of packages). People have been writing packages for Mathematica since the system was first released.
I am concerned about the future of packages (and the planned package repository) because I repeatedly see people express the opinion that “the function repository is sufficient”, when someone writes some useful code that “you should submit it to the function repository”, or simply not even realizing the huge difference between these concepts, and that the more valuable some work is the less likely it is that it is suitable for the function repository.
I do not see how Mathematica could compete with other systems without any well supported facilities to create packages, and I am puzzled about why this is not prioritized over things like the function repo which is just not an alternative.
There are about 6 public functions; since they are all highly related and rely on a shared core, breaking it up into separate WFR entries seemed undesirable.
As noted, not putting all of these functions together in a single package would be dreadful for maintainability purposes.
In addition to what Szabolcs said, you always have the option of putting up your package on GitHub, Bitbucket, or some other equivalent service; additionally, let me also mention posting your package on PackageData, or even create a Zenodo entry for it to let other potential users know about your package.
The remarks by @SzabolcsHorvat and @J.M. about package vs individual function construction are all valid of course. I will point out that there is an intermediate path that is, in some cases, also viable. One can use a “container” function and support different operations therein. (I believe this is a subset of what goes as Object Oriented Programming, but I predate OOP so I’m not really certain). One example of what I have in mind is the WFR entry “ExpressionBag” by Richard Hennigan.
This really only applies in cases where it makes sense to have a single “function” supporting multiple operations. Implementation of specific data structures is one area where this use case might be common. If time permits I might post a related example to Community.
RiemannSurfacePlot3D looks like a cool idea for mainline inclusion. However, often you may want different embeddings for different patches of the surface, see for example:
which uses three different projections from R^4 to R^3. I dream of someday just inputting an algebraic equation, then the graph function returns a best-possible embedding to 3D, but perhaps this is asking too much. How about starting with “TorusPlot[EllipticCurve_]:= 1. Find critical points. 2. expand hyperbolae around them.” ?
I’m not sure if it was this comment or another comment where the issue with PackageData’s URL size limit was raised. In any case, I’m sorry about that! I’ve now fixed it.
Thanks for reaching out. Our events team will contact to get size and shipping details. Congratulations again. Also, I actually used some of your code to beat information from our knowledge base in one of my WFR examples.
