Peter, My point was to make it easier for any new tool writers to choose the same format over something entirely new, there are some examples in the notes. I have not investigated it in detail but there must be some reason why the cabal format is not being adopted or is not likely to be adopted by new tools describing package metadata; I was thinking the format being seen as tightly attached to cabal and not usable in general might be one reason. Is it likely to be seen as an independent format if it has a spec describing it and an independent parsing library? Or is it some entirely different reason altogether? Or maybe its not worth caring about whether all tools use the same language for metadata, I might be the only one? -harendra On 2 November 2016 at 21:46, Peter Simons wrote:

Hi Harendra,

...

It might help if the [Cabal] 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.

I'm not quite sure how to interpret that statement. The parser for the Cabal format is quite modular and re-usable already and has been available in the Cabal library for years:

http://hackage.haskell.org/package/Cabal-1.24.0.0/docs/Distribution- PackageDescription-Parse.html

Am I missing something?

Best regards, Peter

_______________________________________________ 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.

On 3 November 2016 at 13:20, Patrick Pelletier wrote:

One impression I've gotten (although I have not looked into this closely) is that the API for cabal-the-library does not seem to be very stable. From looking at the version history of the standalone-haddock tool, it appears that it has to change frequently for new versions of cabal, and only supports one version of cabal at a time. (And it currently isn't up-to-date with the latest cabal.) This makes it difficult to use, because my cabal is probably too old or too new.

I believe that any version of Cabal can parse files produced for any older versions of Cabal. The API hasn't changed that much that I'm familiar with (I've had to tweak some code that deals with it every time there's a new version, but it's usually not too bad, more that they keep changing where information about PackageDB is found).

--Patrick

On 11/2/16 10:05 AM, Harendra Kumar wrote:

Peter,

My point was to make it easier for any new tool writers to choose the same format over something entirely new, there are some examples in the notes. I have not investigated it in detail but there must be some reason why the cabal format is not being adopted or is not likely to be adopted by new tools describing package metadata; I was thinking the format being seen as tightly attached to cabal and not usable in general might be one reason. Is it likely to be seen as an independent format if it has a spec describing it and an independent parsing library? Or is it some entirely different reason altogether? Or maybe its not worth caring about whether all tools use the same language for metadata, I might be the only one?

-harendra

On 2 November 2016 at 21:46, Peter Simons wrote:

...

Hi Harendra,

...

It might help if the [Cabal] 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.

I'm not quite sure how to interpret that statement. The parser for the Cabal format is quite modular and re-usable already and has been available in the Cabal library for years:

http://hackage.haskell.org/package/Cabal-1.24.0.0/docs/Distribution-PackageD...

Am I missing something?

Best regards, Peter

_______________________________________________ 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.

_______________________________________________ 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.

_______________________________________________ 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.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Funnily enough, it is already, though not in the way you want ;) Excerpts from Alexander Kjeldaas's message of 2016-11-03 15:14:26 +0100:

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 wrote:

...

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.