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) : Generate an almost-right Project.toml file from a REQUIRE file in Julia 1.0 <= VERSION < 1.1- · GitHub
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: GitHub - JuliaRegistries/General: The official registry of general Julia packages 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?