When the package manager - in it’s current state was released, with it’s features for maintaining multiple registries and the like there came talk of having organisation and topic specific registries. I thought it was really cool and jumped to be an early adopter as I could - but at the same time, searching and discovering julia packages in General became much easier and pleasant experience. Now it is how it is. It might be easier after all to just have general absorb it all, and have good tagging and instructions on the website on how to search the package list for biojulia packages.
5 Likes
I am a fan of this proposal.
I’ll be honest, I’ve always been sceptical of the BioJulia registry, and never saw enough benefit to move BioStructures.jl to it. Not that I think it’s bad, I just never saw the big advantage.
I think putting more on biojulia.net is essential, e.g. a list of packages and a couple of examples of how they can be used interoperably as part of an ecosystem.
I am also aware that this kind of work has fallen to a small number of people in the past, most notably Ben, so am happy to help as appropriate.
We have great tools here but the tools are better than the docs, discoverability and overall user experience.
4 Likes
Ok then, I’ll begin the transition.
Yeah it might be good to come up with notebooks and tutorials showing how you can piece together the ecosystem.
We should also perhaps have clear instructions on how to avoid the more common julia pitfalls, if we can stop new users from getting that holding the phone wrong response in the first place it might make a better first impression.
8 Likes
For what it’s worth, it was never the intention for there to be multiple public registries of open source projects. The purpose of supporting multiple registries was to allow fully private (not available to the public) and semi-private registries (available but meant for use within an organization/group). Having multiple public registries of open source projects just hurts their discoverability, IMO, as seems to be the case here. The requirements on the General registry are extremely minimal. Of course we can’t force people to not have separate registries, but it doesn’t seem like a good thing to me.
7 Likes
Ok, the process has begun with BioGenerics, BioSymbols, and FormatSpecimens but it’s 3am so I’m gonna crash. In the comming days, if anyone observing General, with the power to merge anything, notices that CI has lit green something that I’m migrating, that is sat waiting for the 3 day wait for new packages, that would help make it a lot less painful.
3 Likes
I’ll keep an eye on the registry.
2 Likes
Maybe I’m dense or there are complications related to registry CI but wouldn’t it be easier and better to do a wholesale merge of the BioJulia registry into General in a single PR? Assuming there are no name clashes, the package directories (with Package.toml, Versions.toml, Deps.toml, and Compat.toml) can just be copied in. The entries in the [packages] section of Registry.toml would need to be concatenated and sorted, which is easy enough. As a major benefit the historical versions of the packages would be retained.
Edit: Work in progress merge support in LocalRegistry: https://github.com/GunnarFarneback/LocalRegistry.jl/pull/14
1 Like
There are packages that have different versions that span both registries, and I don’t trust myself to manually sort that out in a PR without human error creeping in. But for the packages with no previous entries in General it would be easier.
Manually sounds barbaric but let there be tools. Try this and see if you like the result in /tmp/General (adjust the paths as necessary if you’re not running Linux):
using Pkg
pkg"add LocalRegistry#merge"
using LocalRegistry
run(`git clone https://github.com/JuliaRegistries/General.git /tmp/General`)
run(`git clone https://github.com/BioJulia/BioJuliaRegistry.git /tmp/BioJuliaRegistry`)
LocalRegistry.merge("/tmp/General", "/tmp/BioJuliaRegistry", merge_packages = true)
1 Like
I tried this this morning - I totally did not clock the merge_packages option facepalm.
It probably didn’t exist at the time. 
OMG that merge function has saved my sanity. Thank you!
2 Likes
Ok, everything in the BioJuliaRegistry has been merged into General. I’m going to update the website, but there may be references to the registry in READMEs and old doc builds whilst we get around to hunting them out and correcting them. In the meantime it would help if any users could remove the BioJuliaRegistry and try and do their thing with just General and see if it breaks - it shouldn’t but you know how it is. Soon-ish, say end of bank holiday, I will archive the BioJuliaRegistry.
10 Likes
New Getting Started instructions are available on the website, as is a new post explaining Bio.jl is deprecated, and which packages should be used instead.
2 Likes
What should I do to migrate from BioJuliaRegistry to General ?
Assuming it worked as expected, I think just delete the BioJulia registry (~/.julia/registries/BioJuliaRegistry/), then resolve? I did that (well, I moved the registry instead of deleting, just in case), and that seems to have worked.
I just did pkg> registry rm BioJuliaRegistry and then for my few active projects on my desktop deleted any manifests and instantiated them again. Resolve seems to work as @kevbonham says. Any packages - mostly BioJulia ones that still get the BioJuliaRegistry in their CI in order to work, should work without that step now and so it can be removed from the Travis (or other CI) files.
I think this
Also importantly, the Julia developers do not value backward compatibility.
is a pretty spectacular statement. Are you basing it on version breakage pre v1.0? I think that seems overly harsh, even unfair.
2 Likes
I would go so far as to say it’s so spectacular it’s not worth engaging.
2 Likes
It does me no good to provoke the Julia community here. I will only ask a question: do you anticipate a python2-to-3 like massive breaking changes in the next 5 to 10 years? By “massive breaking changes”, I mean a big fraction of existing code will stop working. I saw brief responses from some of you on hacker news/reddit. The answer was yes. Is that still true? Or maybe those responses don’t represent the opinion of the core Julia devs?
EDIT: also this thread really worries me. Like “Julia 2.0 will come with features that people are dying to have that aren’t possible without breaking things”.