Switching package registration systems soon

Announcements
81

Anyone else ready? Delete REQUIRE · fredrikekre/Literate.jl@dd55c23 · GitHub

5 Likes
82

2 posts were split to a new topic: Trouble registering package

83

Sorry if I missed this earlier in the thread; if we have an existing package in the General Registry that currently only uses REQUIRE, can we use the Package.toml in the general registry to provide the uuid for the new project.toml that needs to be created?

Nevermind, I see that this is answered above. Thanks @Tamas_Papp for confirming the general registry uuid can be used.

84

Currently trying to instantiate a project enviroment (Linux, both latest and 1.1): checking out general registry hangs. Is that expected at this stage?

85

Since today is supposedly the day: I’d like to make a case that we get the REQUIRE->Project.toml script before we make this transition.

9 Likes
86

Is there any documentation somewhere for how to manually register projects with General for projects where Registrator won’t work (e.g. not on Github)?

2 Likes
87

I think it is not quite as simple as a REQUIRE → Project.toml script. Most likely Travis and Appveyor script will also need to be updated.

Btw, adding a Project.toml to an existing package is not too difficult to do manually and only needs to be done once.

  1. cd to a temporary directory and run pkg> generate MyPackage. This will generate a blank Project.toml.
  2. Copy the Project.toml to your deved package folder.
  3. julia> Pkg.activate("path/to/.julia/dev/MyPackage")
  4. For each package in REQUIRE, pkg> add PackageInREQUIRE
  5. If you are using any standard libs, it will complain, so just pkg> add StandardLib until it stops complaining.
  6. Finally, you’ll need to grab a recent template for Travis and Appveyor scripts.

I don’t think this should hold up the transition. It is not that difficult to add a Project.toml to an existing package.

4 Likes
88

They do not. And if you are maintaining many packages, it is understandable that doing it manually is quite tedious.

1 Like
89

Some of us have >100 packages. Imagine that collectively 1000 packages (probably conservative) need to be migrated. Imagine a script saves 1 minute of time per package (probably conservative). That’s 2 full workdays spread collectively across the development community. Now look at the other side: for a developer of Stefan’s talents, cobbling together code (almost all of which is already written for the current METADATA->General system) and posting it up on GitHub is what, 2 hours? It doesn’t have to be perfect (we’ll visually inspect and edit the Project files as necessary), it just has to be good enough to reduce the global effort involved in this transition. And the math indicates it’s not even a close call.

2 Likes
90

Sure. That is why there should be a script to help out.

91

Sure Tim. I’m not arguing against a script. A script would be great and I’m sure its coming. I just wanted to point out that it can be done manually and lots of people maintain just a handful of packages where doing it manually might make sense. I’ve already done it for the handful of packages I maintain and thought it might help to share the steps I worked out for myself. For sure you’re case is different and it makes sense to wait, but I don’t think that should hold up the transition from METADATA. I’m confident that within hours of the transition happening, that script will appear.

92

Someone has to put in the work though — it won’t happen magically. The task is somewhat difficult, since stdlibs were not to be specified in REQUIRE, but they need to be in Project.toml though.

93

We already have the code to detect that in the sync script, it’s just a matter of extracting it, which I’m working on. We won’t be making the transition until Tuesday evening / Wednesday morning because we want @Nishanth_Kottary to be available during the switchover.

3 Likes
94

I have to say that I second Tim’s suggestion that the migration be delayed until we have an automated upgrade script, ideally something integrated with femtocleaner that can submit PRs to registered packages that require Julia 0.7+.

There’s no urgent need to switch this week; it seems crazy to casually disrupt access to thousands of packages.

95

I tried to register a new version of a package, but JuliaRegistrator complains about StaticArrays not being found. However the UUID seems correct:

Pkg.METADATA_compatible_uuid("StaticArrays")
# UUID("90137ffa-7385-5640-81b9-e52037218182")
1 Like
96

We won’t be making the transition until Tuesday evening / Wednesday morning.

Could the main subject/body of this thread be changed with any status changes? ie: “Transition Started”, “Transition moved to Tue/Wed”? At this time, to me, it’s unclear exactly what is happening today (and what is deferred to later). Thanks :wink:

1 Like
97

This won’t disrupt access to anything. This only affects the process of registering new versions of packages. I don’t think that making automatic PRs is worth the difficulty to make that work well. Unlike femtocleaner (which was, of you recall quite hard to keep running), this is a one-time thing.

2 Likes
98

the Metadata sync script should probably keep running, until the actual transition happens?

99

Yes, but unrelated to this process, the machine that it runs on has been down over the weekend and still isn’t back up. It could be run elsewhere but it takes a long time to clone all the repositories.

2 Likes
100

Same issue here with LightXML:

julia> Pkg.METADATA_compatible_uuid("LightXML")
UUID("9c8b4983-aa76-5018-a973-4c85ecc9e179")