Switching package registration systems soon

I would prefer registering. By pushing to the repo on Github/Gitlab/…, I already consider software published (= made public). By registering, I make it known to the registry.

Is it significant that Registrator is under JuliaComputing rather than JuliaLang on github?

1 Like

Any explanation on how to migrate an existing package? In particular, how do I do the equivalent of tagging a new release named (say) “v0.1.2”?

Right now I do this in Github and attobot does the rest. The docs for Regitrator.jl don’t even mention “version” at all…

Yeah, but “registering” a new version is a bit weird imho.

see above. It seems the workflow is to change the version entry in the Project toml and then call the bot with the register command.

Sorry if the information can be found elsewhere. How can we generate Project and Manifest files? Is there a robust (or official) tool for it?

Found those functions (thanks @iamed2) : https://gist.github.com/iamed2/87d2d4d6a458a8072638439fb6070dc0

But before I launch those functions, is there another walk-through that I should consult?

Cheers!

There are no “Project.toml” files in existing packages. How do we make a Project.toml for an existing package to begin with? How do we edit it? Do we just replace “version=v0.1.1” with “version=v0.1.2”?

Not really, aside from that it has thus far been primarily developed by Julia Computing.

1 Like

But that’s what you are doing: you are registering a new version of a package.

It seems like we may need to provide a tool for generating a project file from REQUIRE files. I’ll write a tool and people can try it out.

10 Likes

Fully agree. I find the use of term registering very confusing in this context. For me, I register a package only once, and further update it to new versions.

Whether people find it colloquially weird or not, that’s what you’re doing: you are registering a new version of a package.

1 Like

My two packages have very simple REQUIRE files. In this case, I just need to create a Project.toml with those dependencies using add. However, what I still do not understand is how can I get the correct UUID. Where am I supposed to search for the correct UUID for my package?

EDIT: Oh by the way, will the acceptance behavior of versions / new packages remain the same of that in METADATA?

EDIT 2: I just realized that it is available here: https://github.com/JuliaRegistries/General just need to copy it by hand and create the Project.toml.

1 Like

Just tried it out on a new package I’m thinking of registering soon, using a comment here. I’m not sure, but it doesn’t seem to be doing anything.

In terms of best practices, if the “true” version number now lives inside the Project.toml, should one make sure that it only has a release version number for one single git commit? So say, normally it is v0.1.1-dev, and then I only change that to v0.1.1 for one commit, register that commit in General, tag that commit, and then immediately in the next commit change it to v0.1.2-dev?

On one hand that seems sensible, but also quite cumbersome without some tooling. In an ideal world I would actually be able to tell registrator: “I want to register version v0.1.1”, and it would then do one commit to my repo that bumps the version number to v0.1.1 in the Project.toml, tags that commit, updates General accordingly, then adds another commit to my repo where the version in Project.toml is bumped to v0.1.2-dev.

10 Likes

I think you need backticks surrounding register()

1 Like

Thanks for the confirmation. Will you add a description of a recommended workflow, like the one I wrote, to the pkg docs about how ro register new packages and new versions? If I find time, I can try to add it myself, but that is a bit tricky when not knowing what exact workflow you envision. Furthermore, I find that the pkg docs have improved a lot since I read them last. For me the recipe like descriptions are really helpful.

Finally, I very much appriciate all the good work done on code sharing in julia. I think this is the part of julia I like most, and I find it works much better than in R, matlab and python.

2 Likes

I had originally planned on switching it off, but can keep it running if people are still using it.

The main question is: should it error (i.e. open an issue) if you attempt to tag version > 0.6, or silently ignore it?

silently ignore, so that the automated attobot does not create unnecessary issues if it is not yet removed from a repository that does not support v0.6 anymore

2 Likes

Also, perhaps some additional clarification/reminders about when it’s appropriate to include a Manifest.toml? A bunch of people in this thread are asking about both project and manifest, and the manifest is created when doing ]add to generate a project.toml, but my sense is that most things being registered by Registrator should probably not have a Manifest, is that right?