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. There is a ticket with a patch to support building this style port collection at https://svn.macosforge.org/projects/macports/ticket/12542 I apologize for the early morning rambling... Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On Aug 22, 2007, at 5:34 AM, 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.
why?
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.
there's nothing that forces the gui to adopt a display that mirrors the physical (on disk) layout of the ports. The current categories are there so that humans can browse the ports directory and see related ports somewhat grouped together.
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.
I don't understand what this scheme buys us (other than port maintainers not having to choose a place to put a port). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-08-22 10:13:18 -0400, Daniel J. Luke wrote:
On Aug 22, 2007, at 5:34 AM, Randall Wood wrote:
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.
I don't understand what this scheme buys us (other than port maintainers not having to choose a place to put a port).
But that should be easier to find where a port is located (and the primary category could be changed more easily if need be). Moreover, if this is implemented, I think that prefixes should be optional, so that those who use a local source with a few ports only could choose to avoid prefixes. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Aug 22, 2007, at 10:57 AM, Vincent Lefevre wrote:
On 2007-08-22 10:13:18 -0400, Daniel J. Luke wrote:
On Aug 22, 2007, at 5:34 AM, Randall Wood wrote:
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.
I don't understand what this scheme buys us (other than port maintainers not having to choose a place to put a port).
But that should be easier to find where a port is located
easier than 'port dir portname' ?
(and the primary category could be changed more easily if need be).
How often does this really happen? (and svn mv isn't really that hard anyway).
Moreover, if this is implemented, I think that prefixes should be optional, so that those who use a local source with a few ports only could choose to avoid prefixes.
That might be a useful enhancement. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-08-22 11:06:33 -0400, Daniel J. Luke wrote:
On Aug 22, 2007, at 10:57 AM, Vincent Lefevre wrote:
But that should be easier to find where a port is located
easier than 'port dir portname' ?
'port dir portname' only lists the first directory (when a port is present in several sources).
(and the primary category could be changed more easily if need be).
How often does this really happen? (and svn mv isn't really that hard anyway).
There are drawbacks with some commands when one wants to look at the history before the port was moved. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre wrote:
On 2007-08-22 11:06:33 -0400, Daniel J. Luke wrote:
On Aug 22, 2007, at 10:57 AM, Vincent Lefevre wrote:
But that should be easier to find where a port is located easier than 'port dir portname' ?
'port dir portname' only lists the first directory (when a port is present in several sources).
That's good, otherwise we wouldn't be able to do something like cd $(port dir foo) And that's also the port used if you type a command with this portname.
(and the primary category could be changed more easily if need be). How often does this really happen? (and svn mv isn't really that hard anyway).
There are drawbacks with some commands when one wants to look at the history before the port was moved.
What kind of drawbacks? Even if you did a svn mv in r42 and request an earlier revision 23 via http://.../foo/Portfile@23 subversion fetches it from the old location. That's the advantage of svn mv over pure mv. Rainer
On 2007-08-22 18:11:55 +0200, Rainer Müller wrote:
Vincent Lefevre wrote:
'port dir portname' only lists the first directory (when a port is present in several sources).
That's good, otherwise we wouldn't be able to do something like cd $(port dir foo)
Yes, but one may want the one in another source. Now, the main problem is that it's not always easy to type 'port dir portname' when one has started to type another command.
There are drawbacks with some commands when one wants to look at the history before the port was moved.
What kind of drawbacks? Even if you did a svn mv in r42 and request an earlier revision 23 via http://.../foo/Portfile@23 subversion fetches it from the old location. That's the advantage of svn mv over pure mv.
This doesn't work here. If one wants to use the new URL, one mustn't use @ after the URL (so that the URL from HEAD is considered), but one needs to use -r<rev> instead. There are some cases (I don't remember) where this is less practical. And of course, it's easy to get confused. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
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
On Aug 22, 2007, at 07:13, Daniel J. Luke wrote:
On Aug 22, 2007, at 5:34 AM, 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.
why?
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.
there's nothing that forces the gui to adopt a display that mirrors the physical (on disk) layout of the ports.
The current categories are there so that humans can browse the ports directory and see related ports somewhat grouped together.
Indeed. Why complicate things with weird sub-directories? If you really don't want an on-disk port heirarchy (understandable), then we could just stick them all in one directory. It's a flat namespace, after all. Honestly, though, this sounds like more change for the sake of change. Is there a technical advantage to changing the implementation? -landonf
On Aug 22, 2007, at 11:55, Chris Pickel wrote:
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`.
I don't think anybody needs this level of customization. I don't think the current layout of the dports dir is broken, so I wouldn't change it.
participants (7)
-
Chris Pickel
-
Daniel J. Luke
-
Landon Fuller
-
Rainer Müller
-
Randall Wood
-
Ryan Schmidt
-
Vincent Lefevre