Simplest way to distribute package on shared server?

Tooling Package Management
1

Simple Private Distribution

I have a set of evolving private packages I want to make available for my coworkers to use through our shared file server. What’s the easiest way to set this up so they can call the main branch functions while I am working on a feature branch? This is half a Git question and half a Pkg question.

Git Setup

I noticed if I am working on a feature branch directly on the file server, then File Explorer shows the files in the feature state. I only want the main branch to be (easily) accessible. For this reason, I am now developing the package in a local directory, pushing it to a private GitHub repository, and then manually pulling all merges down to a clone on the shared file server. That seems like a lot of unnecessary steps though. Is there a safe way for me to work on updates directly from the server without these other copies and steps?

Environement Setup

My coworkers do not know how to code or use a terminal. When they call one of my functions, I prompt them to enter each input or select each file. I wrote up a set of instructions for them on how to create separate shared environments for each package and install my packages into these environments by copying the path from File Explorer into Julia’s terminal.

Add vs Dev

Is add the correct instruction for installing my cloned packages into their shared environments? I know dev is used more commonly when pointing to local files, but I figured dev would slow them down with unnecessary precompilation every time?

Shared vs Local Environments

I realized after writing out the instructions that they are not going to be able to follow them to a.) get it set up properly and b.) remember to activate the correct environment before trying to run the analysis. I now think an easier way will be to get them to click on image or image from the server folder and configure their startup files to auto-load local environments.

if isfile("Project.toml") && isfile("Manifest.toml")
    import Pkg
    Pkg.activate(".")
end

Does that sound like a good approach?

Tamper Prevention

Can I still git pull to the server if I make the server clone read-only so they don’t accidently edit stuff in VSCode when they open it? If not, I’ll probably write the instructions to run in Windows terminal away from the code.

(I know the correct future solution is a binary app with a GUI interface, but I need something I can implement more quickly.)

2

You could set up your own package registry on your git server and use LocalRegistry.jl to register your packages there. You colleagues just would add this registry to their Julia installation, and then they can work with your packages in a similar way to packages registered in the General registry.

1 Like
3
  • Definitely set up a local registry if you have any kind of dependencies between your packages. Doing it any other way will just bring you down a rabbit hole of fighting against Pkg. (LocalRegistry was specifically developed for these kinds of scenarios.)
  • Primarily I would recommend hosting your packages and registry on GitHub/GitLab/… either in the cloud or in-house. If that for some reason is not possible or desired, you can emulate it on your shared file server with bare git repositories accessed with file:// URLs. This works with LocalRegistry.
  • If your users are not supposed to modify anything in your packages, they should add the packages and not develop them.
4

Wouldn’t that require they all make GitHub accounts and configure permissions to access the private packages and registry though? What does host on GitHub in-house mean?

I do have the packages on GitHub now, but it basically just serves as a backup and a convenience if I’m on the go. I don’t point anything/anyone to it currently.

5

Yes, they need some kind of credentials but a read-only access token to your repositories could be a possibility.

I don’t know specifically about the GitHub offerings, but for example the GitLab Community Edition is open source can be run on a server in your local network.