Registering in General packages not intended for the general public

General Usage
, ,
1

(This has been spurred by a comment by Stefan on slack#pkg-registration) I’m a researcher at a lab. I write tools in Julia for the lab. I know no one outside the lab would need to use some of these tools. Should I be registering my tools in the General registry or not?

Reasons to why not:

  1. Package names are a shared community resource, so don’t take up names for packages that only a handful would use when those names could be used by more popular packages.
  2. By registering a package you are essentially committing to keeping it registered forever. A package for a tool used by a lab doesn’t seem to fit that bill. A typical tool would be used for a couple of years at most.
  3. Packages at the registry are meant to be useful for everyone. These tools are usually very specific, useful for a handful of people at specific times for a short period of time.

Reasons to why yes:

  1. Everything is automated and feature rich, why not use it? It’s there to be used, and the strain/cost is so minimal that there is no reason not to use it.

I’d like to hear your thoughts about this issue. If you think the general registry shouldn’t be used for such tools, what then are the best alternatives? It would be great if you could link to tutorials/docs when you suggest an alternative.

I’m slowly gravitating towards the answer “No”… But I’m uncertain how to replace the functionality of the registry (what with the registration bot, compat helper, the ease of just ]adding a package, etc.).

Thanks!

2 Likes
2

What part of the automation do you not get if you do not register the package?

  • Compat helper works without registration
  • You can still pkg> add unregistered packages, you just need the full URL
3

True, but what about unregistered packages that depend on other unregistered packages that depend on other unregistered packages etc?

4

This is exactly what the LocalRegistry package is designed for.

4 Likes
5

For those I usually add install instructions in the readme, essentially a series of pkg> add.
You could also set up a lab specific registry from which users could install the packages after having added the registry

6

This is pretty amazing! Would all the other packages in the General registry also be available there, or how would that work?

I’m dealing with people that have very limited technical skills, but yes, that would work.

So I’m assuming you’re referring to @GunnarFarneback’s suggestion?

7

I think we wrote it at the same time, but he was slightly faster at posting :slight_smile:. Yes, we probably refer to the same thing, and Gunnar appears to have a nice way of setting up such a registry I was not aware of.

8

This is great. LocalRegistry seems ideal. I’ll need to see how to have access to the General registry as well (kind of like stacked environments in Pkg), and I’ll give it a shot. Conditional on it working, my next step would be to kill the few public packages I have in the General registry…

9

Just add the local registry and you are done. The General registry is not going anywhere and Pkg reads from all registries automatically.

2 Likes
10

This is awesome!!! Wish I knew about this earlier. OK, here I go killing (my public packages) again!

Thanks everyone!

2 Likes
11

There’s one minor gotcha to be aware of. If you make a new Julia installation and do pkg> registry add <lab_registry_url> as your first Pkg operation, General will not be added automatically and you will need a manual pkg> registry add General.

5 Likes
12

And to avoid that, instead of telling people to:

import Pkg
Pkg.Registry.add(<lab_registry_url>)

I can tell them to:

import Pkg
Pkg.update()
Pkg.Registry.add(<lab_registry_url>)

?

13

There are many ways to induce General to be added. You can easily test what works or not for a new installation by pointing JULIA_DEPOT_PATH to an empty directory before starting Julia. I would probably go with

using Pkg
pkg"registry add General <lab_registry_url>"
2 Likes
14

I confirm that LocalRegistry.jl is a perfect tool for that purpose. I’m using it in my corporate setting to manage the packages that are meant to be used only by my work team.

15

Nice, thanks for the encouragement!