Deprecate old Registered Packages Versions and default to the Newest Version?

package
#1

Hey everyone,

I recently got a package registered on METADATA and all that. I’ve since cut a new and again accepted release. However, when I go to install it via Pkg.add() it prefers to install the old version. How do I let METADATA know that the new version is more stable and the old one shouldnt be the default?

Thanks as always,
casey

0 Likes

#2

I’m fairly certain there is no way to do this. You can always add directly by UUID (e.g pkg> add 682c06a0-de6a-54ab-a142-c8b1cf79cde6) so that there will be no ambiguity.

0 Likes

#3

Are you sure? When I Pkg.add say CSV it gives me I think the latest version. More importantly when I do Pkg.update it updates to the latest version. While Pkg.update leaves my package untouched.

Edit - sorry I realized I was unclear in my original post. I changed the title.

0 Likes

#4

Ah, I did misread your question.

Deprecations are built into the versioning strategy. Given no other constraints, Pkg.add will install the latest registered version of a package.

In your specific case, you were probably using an outdated copy of the registry. You can force a registry update with pkg> registry update (as of Julia 1.1, I believe). Pkg uses a local copy of the registry, but does not update the registry on every command.

0 Likes

#5

For Julia 1.0 is there an equivalent command?

I am just confused. It’s been a few weeks, and when I pkg add I still get v0.2.3. IE:

(v1.0) pkg> add ChemometricsTools
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [a9718f02] + ChemometricsTools v0.2.3

I think the problem is with Julia Registries
IE: https://github.com/JuliaRegistries/General/blob/master/C/ChemometricsTools/Compat.toml

but the latest version on metadata is : https://github.com/JuliaLang/METADATA.jl/tree/metadata-v2/ChemometricsTools/versions/0.3.7

0 Likes

#6

So I did a little more digging on this and tried to install a package at random (AugmentedGaussianProcesses) and found that their latest version 0.4.0 did not automatically pull from the registry but the 0.3.5 did. While they had 2 older releases which were ignored. Does it just take a while for the julia registry to be updated?

0 Likes

#7

Latest registered release is v0.4.0 (7 days ago), but the synch script broke a couple days ago. It was fixed, but seems that it never made it to General (v0.3.4). Might be a good candidate to try out the new Registrator.

1 Like

#8

Interesting. Is this going to replace the Attobot work-flow? Do I need to uninstall attobot to use this? I imagine there would be conflicts if I didn’t.

I’ll probably give this a try with the latest release if so.

0 Likes

#9

Yes, it will replace attobot but they will coexist for a while: attobot operates on the old METADATA.jl repo while Registrator operates on the new General registry repo. Soon we will stop syncing automatically and they will be separate.

2 Likes

#10

How can I tell if the new registrator is working? I installed the app, made it a collaborator, and made an issue including the magic “@JuliaRegistrator register()” statement. But there’s no response or any indication anything has happened(no e-mail, or comment, or whatever).

0 Likes

#11

Casey, I did see some messages showing up, but maybe in your case you need to put back ticks around the register() part:

@JuliaRegistrator `register()`

I got a message pointing that out and after I created a new issue with the back ticks it worked,

2 Likes

#12

I just received the same message. I added the ticks in a new comment and the pull request nearly instaneously appeared. Interesting. I like this new registrator the code is very clean. Hopefully the approval process is about as fast as the attobot situation.

Thanks everyone for making Julia an awesome language!

0 Likes

#13

Just tried the @JuliaRegistrator `approved()` response on the issue, but that command is disabled right now.

1 Like

#14

I literally just did the same thing. I don’t think this registrator is ready for prime time yet? Hmm… Should I go back to AttoBot?

0 Likes

#15

I am under the impression that by using this framework, you are just helping to test it, but at this point this is just a dry run. Attobot & METADATA are not retired at this point.

0 Likes

#16

I see… I didn’t realize that was what was going on. No worries.

So the current state is that attobot/metadata cannot update the general julia registry for new package releases except for some packages(CSV, etc)? But the new Registrator will fix that once it’s online?

0 Likes

#17

I don’t think anything like this is going on — AFAIK METADATA is still synced to General, and attobot works.

0 Likes

#18

Well that isn’t my current experience as per this thread. I’m not sure what I’m doing wrong. I have a more recent version of my package on julia’s registry, but when I pkg.add it, it adds the first release version by default. When I use Pkg.update it doesn’t pull down the latest version either. I have to manually enter the latest version number when I pkg.add/update to get it.

For other packages IE CSV I don’t have to do that.

0 Likes

#19

Yes, it’s just testing right now, but at the end of Stefan’s message

We’re planning to switch from registering packages using attobot against METADATA.jl to registering packages with Registrator against the General registry on Monday. In advance of that, it would be great if people could test out Registrator and see how it goes—currently it’s setup to register new package versions with a dummy fork of General, but the process is otherwise the one that we’ll be using. If you change your registry to point at the fork, then you can use this to install packages as well. It would be greatly helpful if people could try it out.

he requests we test pointing our registry at the dummy fork (not sure how to do that) and without @JuliaRegistrator approved() working it won’t show up anyway I guess.

1 Like