Hi,

Bas van Dijk wrote:
 Tillmann Rendel wrote:
Wouldn't it be more in line with the rest of the cabal infrastructure to
specify the logo file in the cabal file, similar to, e.g., the license file?

Yes it would be more in line. But apart from that, what advantage would it have?

I see this generally about explicit configuration vs. naming conventions.


Naming conventions are seemingly more modular: Old versions or unrelated components of the Cabal infrastructure and even third-party tools will automatically ignore the logo file. However, this modularity comes at a price: Different components or tools might disagree on the meaning of a naming convention. For different versions or components of the Cabal infrastructure, this can be avoided with some global namespace management for the naming convention. It can not be avoided, however, when third-party tools are involved. I think a Cabal package should be able to co-exist with another build or package system in the same directory. But if Cabal treats logo.png specially, and the other system treats logo.png specially in some other way, Cabal and the other system can no longer coexist.

Downwards-compatibility is an instance of this effect. Naming conventions are both more downwards compatible (because old versions just ignore the logo file) and less downwards compatible (because new versions possible break old packages where logo.png is not meant to be a logo).

Naming conventions can be more user-friendly, because the obvious thing just works, and no changes to the cabal file are necessary. However, explicit configuration can make it easier to discover features. For example, cabal-init could create "-- Logo-file: ..." in the cabal file, but it probably should not create a default logo file in the file system. (Or should it?).

Naming conventions can be more or less efficient to implement. Consider the question: "Which packages have logo files?". With a naming convention, this question can be answered for a single package by checking the file system, without reading and parsing any files. But with explicit configuration, this can be answered for all of hackage by just looking at the index, without unpacking any package tarballs.



I see many good reasons for both naming conventions and explicit configuration. I just wonder whether it is a good idea to switch from one to the other in the middle of Cabal's success story.

  Tillmann

_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel

Reply via email to