I didn't see much in the form of problem statement in those threads.
Let me suggest one: A new format should support the megarepo setup. Today
95% of the text in a .cabal file that exists in a megarepo is fluff. It
should be possible to specify a .cabal file in 1-3 lines in a typical
megarepo setup.
- repeating copyright, repo location, ghc options, most of the
dependencies, description, url, author, even version. All should be
inherited. Listing modules seems unnecessary if there are known strategies
for that.
How about making the cabal file a Monoid so it can be composed? I heard
that's a Haskell thing.
Alexander
On Wed, Nov 2, 2016 at 5:05 PM, Harendra Kumar
For reference, I have organized the major points of the discussion that happened earlier on haskell-cafe regarding package metadata format (cabal vs yaml, vs toml, vs hs). Take a look at this:
https://github.com/harendra-kumar/package-metadata
In my opinion, in the short term it might help if the cabal format is improved, the parser is modularized and detached from the cabal tool itself so that it can be used independently by any other tools wishing to do so. For long term possibility of change of format, I do not intend to pursue or investigate it further at this point of time but others who are interested are free to do so.
-harendra
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.