Switching package registration systems soon

has the METADATA to General sync script already been turned off?

1 Like

seems so. I made release of my package yesterday and it is not in the registry but in METADATA. Has Registrator already been modified to point to the general registry?

The machine it runs on got rebooted. I’ll turn it on later when I’m back at a computer.

As there was a lot of negative feedback, here comes something good: Thanks a lot for switching to the new registration system!

I have been using Project.tomls for a while, mostly because I love the feature that I can have separate dependencies only for the testing environment. But this has always implied to do twice the work for a release (changing Project.toml and then doing the github-release stuff). Simply commenting on the commit seems to make it a lot easier. Thanks (:

5 Likes

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

5 Likes

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

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.

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

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

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

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

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

1 Like

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

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

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.

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.

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

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.

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

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