In the Julia community, we proudly say that the line between a developer and a user is thin. This is partially true: Julia packages mostly don’t have a two language problem, and ]dev makes it easy to start tinkering around. However, for somebody interested in writing their first public package for release on the general registry, the barrier to entry is quite high! To write a package with the normal standards of testing, CI, docs, etc. and release it on the general registry, at a minimum you must learn about:
Documeter.jl
Some new Pkg commands, and probably PkgTemplates.jl
TagBot
Registrator
Github
Github Actions
Codecov
And that’s for a “standard” simple package which doesn’t need binary dependencies, artifacts, preferences, etc. Many of these tools mutually depend on each other–for example, if you don’t really know what TagBot is supposed to do and you don’t really know much about Github Actions and you’re looking at a TagBot.yml, quite tricky to interpret what’s going on or what it should look like. (Further fun: even for something as relatively simple as TagBot, well known popular packages have different TagBot.yml conventions. Example.jlCSV.jl)
Is there any official or semi official documentation on the package publishing package, or at least a list of “here’s all the stuff you need to know?” Right now it seems like the implicit strategy is “look at the source code of well known packages and Google stuff you don’t recognize” which seems…not maximally new user friendly.
Maybe it’s secretly a feature that there’s a barrier to less experienced users publishing packages–a kind of quality control? But otherwise what’s the intended solution?
(For context, I am interested in some housekeeping for TravelingSalesmanHeuristics.jl, which hasn’t been updated in quite a while. Since last time I’ve done this, the ecosystem has moved Travis → Github Actions, Documenter has changed, testing and test dependencies have changed, plausibly TagBot.yml has changed, etc. It’s a lot!)
My feeling is this is an area where some blog posts and tutorials would be great. I don’t really know any that walk through the whole process and how all the different parts fit together.
I agree wholeheartedly. It would be highly advantageous to have a centralised resource, where the up-to-date officially supported approach is detailed.
I know of several people who are transitioning to Julia, that got bogged down at the end, because they were confronted with several new concepts at once (automating tests, documentation, versioning, CI, registering, etc.). In such cases, I try to support them as best as I can, but a lot of the resources I reference are scattered across the internet and not always synchronised.
Hence, if there was a definitive guide to point to, that would be a giant step forward in my opinion.
This comment is spot on IMHO: these things tend to move fast. The Travis → GH actions move illustrates how changes in the global Open Source ecosystem can deeply affect the Julia ecosystem of packages.
Although I tend to agree with you, I feel like such blog posts / tutorials could become outdated fairly quickly (and at a rythm that we, as a community, can’t control).
I always felt that one of the great benefits of Example.jl was to provide an example of a Julia package that implements all reasonable Quality Assurance steps (e.g. CI with coverage analysis, documentation update, TagBot, …).
And it “works” at all times, at least I’m not aware of any extended period in time where e.g. CI wasn’t setup in a correct way. In that way, it looks like it’s always more or less up-to-date. I’m wondering if Example.jl could be extended to also become a “tutorial” on package publication. I feel like that could be less prone to become out-of-date than a blog post, especially since we (i.e. the community) can propose PRs to fix out-of-date aspects when needed.
