break up large categories into smaller ones

[cooljeanius (Eric Gallager)]

Currently, when trying to view some directories in the macports-ports repository on GitHub, it is impossible to view all the entries in some of the categories, due to the categories being too large. These are the messages displayed:

devel:

Sorry, we had to truncate this directory to 1,000 files. 222 entries were omitted from the list.

perl:

Sorry, we had to truncate this directory to 1,000 files. 869 entries were omitted from the list.

python:

Sorry, we had to truncate this directory to 1,000 files. 1,039 entries were omitted from the list. 

For categories to be useful, they ought to contain reasonable numbers of entries, IMO, which, to me, implies that the devel, perl, and python categories ought to be broken up. Besides helping people browsing the repository on GitHub, this would also help port discoverability. I'll attach screenshots.

[cooljeanius (Eric Gallager)]

screenshot of truncation message for devel category

[cooljeanius (Eric Gallager)]

screenshot of truncation message for perl category

[cooljeanius (Eric Gallager)]

screenshot of truncation message for python category

[cooljeanius (Eric Gallager)]

Ideas for subcategories for devel:

• autotools (autoconf, automake, gettext, libtool, m4, etc.)
• vcs (version control systems: bzr, cvs, git, hg, and related ports, etc.)
• go (or make it a broader google category, which would include go, since google develops it)
• libs (anything with the "lib" prefix, except for "libtool", which would go in "autotools" as per above)
• move some of the lua ports stuck in devel into the already-existing lua category
• nodejs (would include the various npm ports)

[cooljeanius (Eric Gallager)]

can't think of any way to split up the perl category; only way I can think of to split up the python category is to introduce a subcategory for all of the *_select ports...

[ryandesign (Ryan Carsten Schmidt)]

Other than the GitHub web interface not showing the entire listing, is there a reason why it matters how many ports are in a category?

I already find it inconvenient that ports are in category directories and sometimes wish all port directories were in a single directory (with no category directories). It would eliminate the inconvenience of having to move a port directory to another category directory when wanting to move a port to another category (updating the categories line would then be all you need to do) and it would eliminate the potential for inadvertently putting a port directory into the wrong category directory.

[mascguy (Christopher Nielsen)]

While I understand the frustration with GitHub truncating the list, I also agree with Ryan on the number of categories we already have: For a given port, there are often cases where there isn't a clear-cut primary category to place them in. If it's a development-related port - but also falls into the category of other things, like a system utility, security, etc - it's difficult to pick one.

And if we expand the list of categories, that's simply going to further exacerbate the issue.

EDIT: I'm fine with the set of categories we have today, though: It seems like a good compromise between a reasonable set of categories, without being excessively granular.

[cooljeanius (Eric Gallager)]

Replying to ryandesign:

Other than the GitHub web interface not showing the entire listing, is there a reason why it matters how many ports are in a category?

Well, ease of browsing in general regardless of interface: if I'm scrolling through a category's directory in Finder, or with ls, or something, I'd rather have a shorter list of items in that category rather than a longer one, just generally