[Seeking feedback] Blog post about "Modern Julia workflows"?

Hi everyone,

After watching a nice video by @jacobusmmsmit yesterday, I sat down and thought about all the lore that experienced Julia users keep in their heads. How to write and share code properly, which packages to use and when, etc.
This accumulated knowledge makes our development experience very pleasant, but it is long to acquire and beginners don’t always know where to look.

The official documentation is only part of the story: best practices involve a flurry of external packages, which are constantly in flux. I learned a lot from blogs like https://viralinstruction.com/, and so I thought a blog post could be a good idea. But to make it more discoverable and “official” (which is important for newcomers), I want to add it to the Julia blog.

Below you’ll find a draft of what I’m hoping to cover. Please contribute to this discussion so that we can achieve something reasonably consensual and complete!



Update: the blog posts are being drafted on a separate repo, and we’ll make a PR to the official website once they’re ready.

Preview: https://modernjuliaworkflows.github.io/
Repo: GitHub - modernjuliaworkflows/modernjuliaworkflows.github.io: Blog posts on best practices for Julia development
Progress: Issues · modernjuliaworkflows/modernjuliaworkflows.github.io · GitHub


Thank you for gathering this useful information.

May I ask why there is no reference to projects (like here) as an intermediate step from scripts to packages?

1 Like

Probably a good idea, we’ll put it on the first post with the package manager. Basically my thought was that the first post should be doable with pkg> generate and the second post would involve a more complete structure with PkgTemplates.jl

1 Like

Suggestion: do not suggest installing the LTS with juliaup, people may actually do that and get stuck for years with an old version. Suggest using stable instead.


I’m not sure what you mean? By default, juliaup does install the latest stable release from the release channel, so all I wanted to do was demonstrate another version that you may want to have. To me the most useful are lts and alpha, but I’m open to suggestions.

1 Like

I think we should also provide a simple startup.jl file with a few bare essentials like Revise.jl, PkgTemples.jl and maybe OhMyRepl.jl or other things people consider ‘bare essential’. Maybe, if there are too many opinions on what should be considered “bare essential”, we could feature a “startup.jl generator” of sorts by providing some checkboxes on what packages (each with a brief explanation) to include?

1 Like

Yeah that’s the plan. Provide a basic startup file in the body of the blog, and attach a more sophisticated one for those who want to go one step further.

That’s actually a great idea for a package! And it would be a cool outcome of this blog to improve global tooling. For instance I’m currently busy with adding lots of new stuff to PkgTemplates.jl


I have actually started in that direction a few days ago - the idea is to provide GUI for creating a project/package, because PkgTemplates.jl is overwhelming for a novice (even without the “lots of new stuff” :stuck_out_tongue_winking_eye:). I started from the packages in the default environment, see GitHub - Eben60/PackageIABlink.jl - which is in a very rudimentary state yet.

My knowledge of all that GUI staff is obsolete and very limited, I’m not too productive in programming and all that has nothing to do with my job. If somebody takes the project over or helps substantially, I’d only be glad. I actualy wanted to wait until I have something to show, but coming out now to avoid a parallel development.

1 Like

A bit, yeah :sweat_smile: Hopefully initiatives like our blog post or your package can also contribute to clarify the flurry of options, in a way that can be fed back into the documentation of PkgTemplates.jl

The lack of an easy example is a known issue, even writing a simple tutorial for the PkgTemplates.jl docs could be very useful!

Why not use terminal menus instead of HTML? Actually, that’s exactly what PkgTemplates.jl does. Your life would be much much easier.
But I do believe it might already be duplication of efforts: perhaps improving the item descriptions in the PkgTemplates.jl menus themselves would be faster for a similar reward?

The idea is to provide sufficient explanation texts and external links, among other things, and thus to enable using the thing without reading the manual first. I am not sure it is possible with terminal menu. GUI is what the most people use on computer for a reason.

The thing is that the first juliaup command encountered by the reader is the following one:

juliaup add lts

What @giordano tries to convey (I think) is to explicitly add the juliaup add release to the workflow before suggesting the usage of other channels/versions (and I am posting this because I am of the same opinion).

I know that you have a block of text, that, carefully read, might drive the reader to use the release instead of lts, but many people might just seek the actionable information (e.g., what to do exactly - and that is the lts install in the current context).


I agree! So I went ahead and quickly threw together StartupCustomizer.jl (name up for debated) :slight_smile:

I made a new thread for feedback/discussion of that effort over here.

1 Like

OK that makes sense, I’ll add it, specifying that this is the command executed by default

1 Like

Should LocalRegistry.jl be mentioned? I find it a useful workflow tool to have a personal registry to organize my own code base. But maybe that’s too particular.

May I suggest not to use “Modern” in the title? It get confusing fast…


It will be, on the page about sharing packages

You may, but “Julia Workflows” is kinda boring ^^ Besides I would like to keep the posts updated, so I do hope they remain reasonably modern for at least one or two years

1 Like

Nice. Though I was referring to the value of LocalRegistry even for a single developer, as a way of organizing your own growing code base (with SemVer!) and being able to refer to old functionality by name. I wonder if other people do something like that.


may suggest people might be doing something similar … ?

That also makes sense. The distinction between the three pages is arbitrary anyway, but in the “sharing” page I also include everything related to reproducibility and trustworthy development

1 Like

Since Julia is supposed to be a modern language, it might make more sense to just call them “Common Julia workflows”?