On Fri, Sep 16, 2016 at 4:35 PM, Imants Cekusins
Would cabal-install need to link in all these maintained libraries statically? Or would there be some plug-in mechanism to load them on demand?
well the libraries would need to be official and some with the packager.
the formats would be perfectly interchangeable i.e. cabal -> standard_type -> yaml -> standard_type -> json -> standard_type -> cabal would produce the same cabal file
only 1 config file per package to avoid confusion
however if the user prefers working with format F, they can always convert the format which came with the package, to F
Even just looking at the set of features which is 1:1 betw. YAML and JSON,
we're essentially just talking about key-value pairs with a couple of
common types for the values. This isn't all .cabal files contain (e.g. see
hvr's points about conditionals), but if it were true, is it really worth
changing how Cabal works for a diffferent color bikeshed?
On Sat, Sep 17, 2016 at 8:06 AM, Imants Cekusins
Do I have to obtain whatever whizzy new controller you've come up with in order to work with your packages? Do I have to do this when everyone has come up with their own whizzy new controller and I need to fit their packages into whatever I am trying to write? that's the while point. If we could agree on a standard serializeable model, each controller would ensure the link between the *view* and the *model.*
user could open a package in any IDE / environment. The environment's controller would display the model in its own / user preferred view.
Why not have .cabal files be the standard model, and anyone can write tools on top to translate to/from .cabal if users really want to use something else? In general, though, I don't think the fragmentation is worth it. Tom