Long story short: I convinced my institution to let my team use Julia for modelling. The catch is that I have to maintain a local repo of packages. How do I get started with that? Is that what LocalRegistry.jl does?
I also have to scan those packages for security vulnerabilities (I was specifically pointed to the Secure Julia Coding Best Practices by JuliaHub). I tried getting familiar with StaticLint.jl without much success. Is there a guide for this that I overlooked?
My background is more of a Julia user for scientific computing (who would have thought?), not really a system admin. Any advice would be appreciated.
LocalRegistry.jl just provides the registry (a standard mapping of package version to git sha), it sounds like you will also need a git server where you actually store the source code itself, in fact your local registry is itself just a git repository and would very likely be stored on the same server. For some people, this could just be a Github organization, but if your institution wants you to have better control over it than a Github organization, any other capable server is okay (including one on a private network).
But there are other solutions to this task as well, depending on the needs. The above (except for the Github part) is what I use and is the simplest.
It depends if you want to have a local repo for your own packages or packages developped inside your organization or to have a local copy of general packages you may want to use (ex: Makie, DifferentialEquations, etc.)
Local packages are to be stored in a Github organization or equivalent (we use BitBucket on a private server), and LocalRegistry is used as a link from the github
repo to your julia install.
One way to do it is to configure a “storage server” on a machine exposed to the internet, and to use it as a proxy to request packages with the package manager (eg “]add JSON”). That will store packages locally as you request them, and you should not access Github servers on the internet next time you request it. Then you have to transfer the stored packages on the network drive you may want to use.
It is not straightforward though, and you will have to parameter registries and package server on the way. Another trick is that you will not have all the versions available, only those you have downloaded at some point. That may be a problem given that a configuration for a particular projet (Project.toml) may differ from another by packages versions and you may have a lot of work to download all the versions for all configurations you may encounter.