I just wanted to bring people’s attention to https://github.com/JuliaOpt/Optim.jl/issues/358 . Now, let me say upfront: we’re not doing a popular vote, I just wanted to let people have a chance to comment.
Basically, JuliaOpt is getting streamlined such that it is only for MathProgBase and related packages (JuMP+extensions and backends). We’re looking for a new name, and currently JuliaNLSolvers seems to be quite popular amongst the usual contributors. In reality, it’s not super important. It’s just the place for the packages to live on Github. Packages keep their names, and so on.
This new org will have a pretty specific package setup: A base package, a line searches package, the Optim package, an NLsolve-ish package (probably NLsolve exactly, but licensing issues just needs to be sorted out), and various auxiliary packages (tests etc). The idea is that the equations solver and the optimization package will have very similar code base and API (much like now, but the link will be strengthened even more).
I also find the naming scheme very weird. MathProgBase/JuMP crew chose to name everything around mathematical programming, docs are all as linear programming, convex programming, etc., but take the org name JuliaOpt, and so the package Optim has to move somewhere else?
That sounds so much more sensible, and I only see a problem of inertia stopping it. But hey, if type definitions were just renamed, we might as well do the sensible changes now pre-1.0.
I hope the Base package makes the API non-package specific. There are some good nonlinear solvers outside of this crew (Kinsol from Sundials is one, Roots.jl is another). It would be great for library code to finally have swap-ability between them, a la
Do you have an idea for what this API is going to be looking like? We can talk more in the chats if it’s still at an idea stage and don’t want to set anything in stone, but I know you’ve been working on it for a bit so maybe there’s already a proposal somewhere?
I Would love to separate the interface and actual solvers further.
Regarding the naming. I get your points, but I think it is very much because of history and personal attachment to the name. I think it’s great that some people are proud of the work they’ve done. For all I care optim could be in an org that was called JuliaPackageCollection. In the end it’s all about the people working on the issues and PRs and the code we provide to the community.
Yeah, I think the organization that hosts the package is totally irrelevant. I think JuliaOptim would be a fine name despite being confusable with JuliaOpt, but I’m fine with the package going anywhere.
As Miles said in a private thread, I think the package organizations have proven to be largely useless. They don’t come with any SLA’s and they only standardize a set of committers.
Patrick’s phrasing of JuliaOpt and Optim “breaking up” is a bit over dramatic and I assume used for ironic effect. What’s happening is that we’re restructuring the GitHub organizations (whose purpose is to facilitate managing permissions for collaboration over a set of GitHub repositories) to match up with the state of reality that the “MathProgBase family” and “Optim family” of packages have grown into their own distinct communities with few overlapping contributors. The idea of having one centralized GitHub organization for all of optimization in Julia dates back to quite a long time ago and in retrospect was never much more than wishful thinking.
The JuliaOpt GitHub organization will be refocused on the mathematical optimization packages including JuMP, Convex.jl, JuMP extensions, and solver interfaces which can currently be characterized as all interacting with the MathProgBase abstraction layer. We will not, however, be renaming the GitHub organization to match the name of the abstraction layer which itself is the result of the quirk of having a short period of time during which JuMP was named “MathProg”. This decision was made amicably in consultation with the package authors, many core contributors, and founders of JuliaOpt and is not subject to public bikeshedding.
The roll-out of this announcement was not quite smooth, and we still have updates to make to juliaopt.org etc.