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!
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
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.
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?
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” ). 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.
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?
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).
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.
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
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 … ?
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
). I started from the packages in the default environment, see 
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