# The tooling barriers to writing+publishing a package
**URL:** https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986
**Category:** General Usage
**Tags:** packages
**Created:** [July 9, 2022, 1:09pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986 "2022-07-09T13:09:58Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@evanfields](https://discourse.julialang.org/u/evanfields)
#### Post date: [July 9, 2022, 1:09pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986/1 "2022-07-09T13:09:58Z")
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.jl](https://github.com/JuliaLang/Example.jl/blob/master/.github/workflows/TagBot.yml) [CSV.jl](https://github.com/JuliaData/CSV.jl/blob/main/.github/workflows/TagBot.yml))
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](https://github.com/evanfields/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!)
---
### Author:  [@cormullion](https://discourse.julialang.org/u/cormullion)
#### Post date: [July 9, 2022, 2:06pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986/2 "2022-07-09T14:06:36Z")
There’s room for some more words here:
[https://pkgdocs.julialang.org/v1/creating-packages/#Registering-packages](https://pkgdocs.julialang.org/v1/creating-packages/#Registering-packages)
Perhaps, though, some would argue that topics not directly linked to Pkg.jl functionality doesn’t belong here. 🤷🏻♂️🛖🚴♂️
---
### Author:  [@ericphanson](https://discourse.julialang.org/u/ericphanson)
#### Post date: [July 9, 2022, 2:15pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986/3 "2022-07-09T14:15:22Z")
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.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [July 9, 2022, 2:26pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986/4 "2022-07-09T14:26:47Z")
This is what I do:
Create a package with a template:
[https://m3g.github.io/JuliaNotes.jl/stable/new\_package/](https://m3g.github.io/JuliaNotes.jl/stable/new_package/)
And publish docs:
[https://m3g.github.io/JuliaNotes.jl/stable/publish\_docs/](https://m3g.github.io/JuliaNotes.jl/stable/publish_docs/)
---
### Author:  [@aegger](https://discourse.julialang.org/u/aegger)
#### Post date: [July 9, 2022, 2:38pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986/5 "2022-07-09T14:38:28Z")
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.
---
### Author:  [@ffevotte](https://discourse.julialang.org/u/ffevotte)
#### Post date: [July 9, 2022, 2:47pm UTC](https://discourse.julialang.org/t/the-tooling-barriers-to-writing-publishing-a-package/83986/6 "2022-07-09T14:47:36Z")
> [@evanfields](#):
>
> 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!
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.
> [@ericphanson](#):
>
> 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.
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).
> [@evanfields](#):
>
> (Further fun: even for something as relatively simple as TagBot, well known popular packages have different `TagBot.yml` conventions. [Example.jl](https://github.com/JuliaLang/Example.jl/blob/master/.github/workflows/TagBot.yml) [CSV.jl](https://github.com/JuliaData/CSV.jl/blob/main/.github/workflows/TagBot.yml))
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.