gdalle
1
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!
https://modernjuliaworkflows.github.io/
52 Likes
gdalle
2
21 Likes
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
gdalle
4
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.
15 Likes
gdalle
6
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
gdalle
8
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
2 Likes
Eben60
9
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” 
). 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
gdalle
10
A bit, yeah 
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?
Eben60
11
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).
7 Likes
I agree! So I went ahead and quickly threw together StartupCustomizer.jl (name up for debated) 
I made a new thread for feedback/discussion of that effort over here.
1 Like
gdalle
14
OK that makes sense, I’ll add it, specifying that this is the command executed by default
1 Like
e3c6
15
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…
2 Likes
gdalle
17
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
e3c6
18
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.
This:
may suggest people might be doing something similar … ?
gdalle
19
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”?
9 Likes
