Pull-first

[BioTurboNick]

Unless there's a conflict, is there any reason not to pull the remote copy of the registry first if the local copy is not synced with it?

Would be nice to not have to manually pull when trying to register a package on a different machine.

[GunnarFarneback]

Are you talking about a git pull which is equivalent to Pkg.Registry.update() or some other scenario?

Possible reasons not to pull automatically are that it's something that can fail (and needs additional complexity to handle that), something that takes extra time, something that Pkg usually tends to do frequently anyway, or something that's not really LocalRegistry's business. But I'd need to understand the use case better to analyze how significant those objections are compared to the value of doing it.

[BioTurboNick]

Sure.

So I'm working on packages that are included in a private registry. Usually they're consumed remotely and produced locally. I also work on multiple computers, so if I register a package on one computer, and then try to register a package on another computer, I get an error that the local copy is behind the remote copy and so it can't complete the operation. So I have to go manually pull from the remote copy of the registry and try again. It always succeeds without issue.

[GunnarFarneback]

I assume you're registering against an installed registry using the no-argument register() call. I believe you can replace the manual git pull with a

pkg> registry update

without leaving Julia. Usually Pkg tends to update the registries automatically when you do certain other operations, but maybe your workflow doesn't trigger that.

Anyhow, I'm open to pulling the remote if the need to do so can be detected cheaply enough.

[BioTurboNick]

Glad to have a workaround! Yeah, guess my usage is a bit of an edge case.

[anushasekar1]

Not such an edge case, we have been running into this a lot in our team as well. Our workflow is almost identical to BioTurboNick's. Would it be too difficult to add an option to update registry in the register method? It could be an option that is false by default. While we can do two steps, ] registry update; register(<package name>), it would nicer to be able to do it in one step register(<package name>, update_registry = true) or something like that.

[tamasgal]

I just hit the same thing and ended up in merge conflicts. I think that fetching/pull (maybe even rebasing) would be a good idea 😉

[GunnarFarneback]

Automatic rebasing is out of the question. Defaulting to making a temporary git clone could be an option, or having an explicit way to opt in to that. Cf. https://github.com/GunnarFarneback/LocalRegistry.jl/blob/master/src/LocalRegistry.jl#L152-L155

[tamasgal]

I think I was not clear enough with the "rebasing". What I meant was that if LocalRegistry.jl already made commits and a git fetch reveals that the registry has changed meanwhile, it could/should rebase its own commits on top of main.

Anyways, I start to believe that this is probably a bit too much for these rare cases. 😄

[BioTurboNick]

Instructing people to try ]registry up in an error message when this fails would be a nice halfway point.