Package logo's

[Tillmann Rendel]

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