Closed zsunberg closed 7 years ago
I'm not against the idea, but what happens to tooling packages going forward? It probably makes sense to decide case by case wether a new package that contains more general tools should be registered or not. Maybe we can put those kinds of issues up to a vote, and also be strict about adding new packages to the JuliaPOMDP project.
Anyway, its a yes from me on registering the two packages, and merging GenerativeModels to POMDPs.jl.
It feels like POMDPs.jl should be the base and not bring in GenerativeModels, but I'm willing to be persuaded. I agree that GenerativeModels.jl is too generic a name, but perhaps POMDPGenerativeModels.jl would be okay?
Having wanted generate_*
functions in POMDPs.jl from the start, I am, of course, somewhat biased towards that idea :-) I don't think they would pollute the interface too much and it would be nice to have both the "explicit" and the generative model interfaces in one place.
I am ok with registering POMDPToolbox and POMDPModels, as these two are fairly essential, but agree with @etotheipluspi that going forward we need to be selective with what we register and what we add to JuliaPOMDP.
Why not just have a submodule for GenerativeModels
inside POMDPs.jl
? People can ignore the submodule if they don't need it.
Hmm... I remember that JLD used to be a submodule of HDF5, but they moved away from that. I wonder why. Their case is different from ours though because our package is just an interface. I don't really like that idea because it is not common, but I could probably be persuaded.
POMDPGenerativeModels.jl seems too long to me. Maybe POMDPGen.jl (and maybe implement JuliaPOMDP/GenerativeModels.jl#11).
There's no technical issue with having all of the functions in POMDPs, and I don't think adding the generate_
functions in would be bloating the package. The only issue is communication. How do we communicate that these functions are alternate to the explicit model interface?
I'm okay with it being included directly.
using POMDPs
using POMDPs.Generative # Don't use this if not a generative model
I agree that adding a few more functions won't bloat the package. But creating a submodule seems the most appropriate way to handle this. Just because submodules are not yet that popular shouldn't mean they should be ignored.
Is there a consensus on wether GenerativeModels.jl should be merged into POMDPs or not?
I'm convinced it should be, and I don't think there's a need for a submodule. I don't think a submodule makes things any clearer than good documentation and examples. @mykelk told me he's on board with whatever we decide. I was planning on merging it in sometime this week if I have time.
Working on this right now
Ok, got generativemodels merged into POMDPs master - now going to tag POMDPs, then will tag other packages sometime next week (before OSS4DM)
Order of things that need to happen to finish this
This is done - woo!
Hey guys,
So I was thinking about registering ParticleFilters on METADATA because it might be useful to people outside of those using POMDPs.jl. One barrier to that is that it depends on GenerativeModels. GenerativeModels seems like too generic of a name to register. Thus, I guess our best way forward would be to roll it into POMDPs.jl.
While we're at it, it seems like we should register POMDPToolbox because it is where nearly all of the functionality is right now. And in order to test POMDPToolbox, we would need to register POMDPModels. Then the only things left unregistered would be solvers (which might not be good to register because a lot of them are acronyms) and other problems that people might implement.
What does everyone think?
This also might mitigate people concluding things like this (from an actual post):