Closed musm closed 7 years ago
I've always been pretty publicly for this since my first METADATA PR. I still think DifferentialEquations is too long. Maybe Pkg3 could alias names, so DiffEq
and DifferentialEquations
point to the same thing? That way it would have a clear name and a short (and clear) name!
Any name change has to go by @tkelman. Name changes don't work very well with METADATA, so it might be smart to, if we agree on it, slate the name change as a Pkg3 change.
sounds good. Since 0.6 is end of year, I suppose we don't have to wait long for Pkg3
What about having a DiffEq.jl which just reexports DifferentialEquations.jl? That would be a simple alias package which would be nice to have (also, who else could sensibly use the name at this point?)
-1 from me. First DifferentialEquations.jl
is a nice name. Second, that package is not the sole purpose of the JuliaDiffEq
organization, which the DiffEq.jl
name would suggest.
Second, that package is not the sole purpose of the JuliaDiffEq organization, which the DiffEq.jl name would suggest.
As of yesterday, DifferentialEquations.jl is now pretty much a common slate for the JuliaDiffEq since all of the functionality moved out to separate packages. I mean, the full code is this:
module DifferentialEquations
using Reexport
@reexport using DiffEqBase
@reexport using StochasticDiffEq
@reexport using FiniteElementDiffEq
@reexport using DiffEqDevTools
@reexport using OrdinaryDiffEq
@reexport using AlgebraicDiffEq
@reexport using StokesDiffEq
@reexport using DiffEqParamEstim
@reexport using DiffEqSensitivity
end
It's a little misleading because actually, OrdinaryDiffEq is also using Sundials, ODEInterface, and PR49 together in the "pre" version of the unified interface, and it documents all of it together. Once the common interface is in the distributed form and things like DASSL plug in, the code will be
module DifferentialEquations
using Reexport
@reexport using DiffEqBase
@reexport using StochasticDiffEq
@reexport using FiniteElementDiffEq
@reexport using DiffEqDevTools
@reexport using OrdinaryDiffEq
@reexport using ODE
@reexport using Sundials
@reexport using ODEIterators
@reexport using DASSL
@reexport using AlgebraicDiffEq
@reexport using StokesDiffEq
@reexport using DiffEqParamEstim
@reexport using DiffEqSensitivity
end
and it will document using the common interface and the add-on components. The only thing that's left out is ODEInterface, which is both not DiffEq and it has build issues on many setups. (ParameterizedFunctions will be here as well after SymEngine makes build issues more safe). So since all of the algorithms / functionality moved out to metapackages, it really just will be the set of functionality which is available via the common interface. You can then use any component directly, but this will be the package which will solve any differential equation with any method defined in JuliaDiffEq.
What I was saying about an alias is that we could just have a DiffEq package which does
module DiffEq
using Reexport
@reexport using DifferentialEquations
end
and so it's a nice shorthand for whoever wants it. I don't know if registering this would every fly though.
-1 from me. First DifferentialEquations.jl is a nice name. Second, that package is not the sole purpose of the JuliaDiffEq organization, which the DiffEq.jl name would suggest.
Well, it kinda already is. And I think Chris's intention is to have it be the Plots.jl
of the DiffEq world.
But that's unrelated to the original intention which is for ease of discoverability of the packages centrality to the ecosystem.
As the title says, DiffEq.jl fits in with the rest of the orgs organizational and name structure. It would also make it easier for others to identify its centrality with respect to the solvers and the other helper packages.
I'm not sure if creating another package which just reeexports things is a good solution. IMO it's best to either rename it completely or to not. Clearly this should be done asap so it doesn't get too ingrained (the original name DifferentialEquations.jl
) or wait until Pkg3 until a better solution arrives (although who knows when that will arrive and by then it might be more annoying since the package will likely become more popular). Ultimately, however, it's Chris's decision.
Well, either way. Still, I think DifferentialEquations.jl is a nice name and it stands out fine in the jungle of packages of JuliaDiffEq. Also, unlike with Plots.jl there will be different entry points and one could well just use DiffEqBase
when wanting to solve an ODE.
Also, unlike with Plots.jl there will be different entry points and one could well just use DiffEqBase when wanting to solve an ODE.
Indeed, this is one way how our design improves upon Plots.jl: by distributing the common interface not only can you have different entry points, but these different entry points can still have a common API.
I do want to note that it would probably be a good idea for DiffEq members to follow the "new" DifferentialEquations.jl repository. Since all of the algorithmic issues have moved to separate repositories, what the issue now contains is just:
A lot of these discussions are started by or carried on by users, like this one for example: https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/47 , and so since they are very user-facing they belong there. This Roadmap repo is just for dev roadmap discussions (like we've been having), mostly because I don't think most users would ever find this repo.
This Roadmap repo is just for dev roadmap discussions (like we've been having), mostly because I don't think most users would ever find this repo.
That's why I pinned it instead of DASSL. I think the discussions here are more important at this point.
I think the ship has sailed on this one.
As the title says, DiffEq.jl fits in with the rest of the orgs organizational and name structure. It would also make it easier for others to identify its centrality with respect to the solvers and the other helper packages.