I’m trying to assemble the beginnings of one, and I’d like to study a few non-trivial but not too huge examples before getting my code in shape for wider publication. Any suggestions?
DataInterpolations.jl
Shameless self-plug:
SplineGrids.jl
2 Likes
Another shameless plug: GitHub - lanl-ansi/MathOptAI.jl: Embed trained machine learning predictors in JuMP
It’s got tests, it’s got docs, it’s got extensions in ext. It has CI stuff like JuliaFormatter. It’s a nice design for a plug-in type architecture that leverages Julia’s multiple dispatch.
4 Likes
OhMyThreads.jl
DifferentiationInterface.jl
Mooncake.jl
Ranging from fairly small but non-trivial to fairly complex. All of them were written from scratch fairly recently in a fairly short timeframe and with a lot of experience from previous projects, so I believe they are almost as clean as any codebase can be given their respective scopes.
8 Likes
You may also want to check out https://modernjuliaworkflows.org/sharing/
8 Likes
Just saw the title of the arxiv paper for diffferentiation interface,
“Sparser, better, faster stronger”
Cyborg-Marianne would be proud. 
3 Likes
These are great!
Thanks, everybody.
2 Likes
In these examples, using and export keywords always occur at the top level, before and after includes. I can make arguments in why that is preferable to using the keywords inside included files, as I have been doing, but I am not sure I believe them. Is this a widespread practice, or a matter of preference?
I’ve seen it quite often, and I think it’s a good practice; have one standard place with an overview of all imported and exported names.
2 Likes
At least for the part of using, doing it at the top level (and before includes), that’s also good practice to reduce the risk of increased loading time due to code invalidation. Or at least that is the message that I understood by reading this nice article - highly recommendable for all package authors, I think:
Specifically this assertion:
1 Like