Categories are evil

[Chris Pickel]

On 22 Aug, 2007, at 5:34, Randall Wood wrote:
> Well, no, not really. Its just that I think that they are a really  
> bad way to physically organize the ports collection.
>
> I understand that categories are an important and useful tool for  
> organizing and grouping ports, but when thinking about a GUI for  
> the MacPorts system, I realized that categories should best be  
> thought of as a set of semi-standardized keywords which any  
> mechanism for searching for ports should recognize. I have also  
> been long bugged by the need to decide which category is the  
> primary category for a port when placing it in the ports collection.
>
> I understand the rational for Juan's desire to move the ports tree  
> out of trunk, and would like to suggest that when (if) that  
> happens, that the structure of the ports collection should, at the  
> same time, change from collection/category/port to collection/a/ab/ 
> port, where 'a' is any lowercase alphanumeric character and 'ab' is  
> a combination of any two lowercase alphanumeric characters, and  
> that any port in directory a/ab should start with the characters ab.
>
> I understand that some directories under the proposed scheme may be  
> large, such as /p/p5, /p/py, /g/gn but it seems that this would not  
> be any real change from the current situation for the perl, python,  
> devel, and other directories that exist now.

Personally, I would like to see an "Portdirs" (or some such) file  
added to ports/, containing a list of dirs to search for for  
portfiles. The current one would be:

aqua/*
archivers/*
audio/*
...
zope/*

and yours would be equivalent to:

a/*/*
b/*/*
c/*/*
...
z/*/*

I think the default should be "*/*" for backwards compatibility, but  
a Portlist of "*" would provide a prefix-less repository as alluded  
to later in the thread.

What this buys us is:
  * We can set up deeper hierarchies; there are plenty of python,  
perl, &c. ports that are basically "a textproc port for python" and  
these could be in e.g. "python/textproc".
  * We can exclude, say "groups" and put the PortGroup files there,  
allowing us to sync the PortGroups with the ports tree.
  * Users have flexibility to determine their own organization scheme  
for their personal repositories, including the prefix-less "*".

I'm bringing this up because I think it's a more flexible  
modification; I don't personally see the need to change the port  
hierarchy to alphabetical organization. A GUI tool can organize the  
tree however's appropriate, and when I want to cd to a port's  
directory, `cd */mpd` works fine if I don't remember it's 'audio'.  
Under your scheme I'd just switch to `cd **/mpd`.


Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070822/d8a6cab0/PGP.bin