Hi Ryan, On Apr 16, 2007, at 5:16 PM, Ryan Schmidt wrote:

On Apr 16, 2007, at 18:41, James Berry wrote:

...

In other words, if you have a file at ~/.portsrc, you should move it to ~/.macports/ports.conf.

Why might one use such a file? What might one put in it?

The contents are the same as what is in ${prefix}/etc/ports/ ports.conf. See man ports.conf(5). This is a way to have a per-user version that would override the system settings. Note that if the user-specific version is found, the system settings are not read at all. James.

Hi Juan, On Apr 16, 2007, at 6:28 PM, Juan Manuel Palacios wrote:

More than a comment, a question actually. If I recall and read it correctly, the previous conf file initialization code in base/src/ darwinports1.0/darwinports.tcl allowed only for one file to exist, either in the environment, ${prefix}/etc/ports/ports.conf or ~/.portsrc, in that order of precedence, iirc. They were all mutually exclusive, meaning that the sole presence of one would rule out the previous one(s) and therefore you could not have system wide values for options foo and bar in, say, ${prefix}/etc/ ports/ports.conf, and override only the value of bar in ~/.portsrc; supposing foo is some mandatory key in the conf file, like $ {prefix} itself, having only bar in ~/.portsrc would cause our base code to complain about foo not being found (and therefore abort). In other words, the previous code effectively allowed only for a single conf file with all the needed values concentrated in it, no spreading them around. So onto my question finally: is this still the case? If so, is this something we want? OK, that's two questions, I know ;-)

I intentionally kept the behavior the same as it was before. I think there are arguments to both behaviors (overriding the whole file vs overriding duplicate fields). Overall, the "only one file wins" strategy is probably simplest to understand, and since we don't have that many settings, probably not onerous for the user. I actually came upon this issue again when I added the (hidden) feature of parsing options from ~/.macports/user.conf. Should this file be allowed to contain only per-user settings (such as submitter name, submitter email, etc, for mpwa) or should it also allow the ports.conf settings to be overridden? I decided on the former, but once again there may be arguments to have _this_ be the mechanism to allow per-setting overrides for the system configuration settings. (For those curious, there are no settings read from user.conf that currently do anything, but the idea is that this will be a source of information about the current user, used while submitting ports to mpwa, which isn't yet available.) James

Hi Juan, On Apr 17, 2007, at 10:33 AM, Juan Manuel Palacios wrote:

On Apr 17, 2007, at 11:59 AM, James Berry wrote:

...

I intentionally kept the behavior the same as it was before. I think there are arguments to both behaviors (overriding the whole file vs overriding duplicate fields). Overall, the "only one file wins" strategy is probably simplest to understand, and since we don't have that many settings, probably not onerous for the user.

I actually came upon this issue again when I added the (hidden) feature of parsing options from ~/.macports/user.conf. Should this file be allowed to contain only per-user settings (such as submitter name, submitter email, etc, for mpwa) or should it also allow the ports.conf settings to be overridden? I decided on the former, but once again there may be arguments to have _this_ be the mechanism to allow per-setting overrides for the system configuration settings. (For those curious, there are no settings read from user.conf that currently do anything, but the idea is that this will be a source of information about the current user, used while submitting ports to mpwa, which isn't yet available.)

James

I think that if we allow overriding of conf values in a user confined doc like ~/.macports/user.conf, we should go ahead and allow selective overriding from existing conf files and dump the current behavior (overriding duplicate fields --proposed behavior-- winning over overriding whole files --current behavior--, borrowing from your wording). I am sure explaining to users they cannot override system wide settings in ~/.macports/ports.conf but that they actually can in ~/.macports/user.conf, while also explaining that if they have ~/.macports/ports.conf they have to insure it is self contained (that is, every single value for keys that mp needs to function properly are in that file), will get pretty confusing. Hell, I even had a hard time writing that just now! Not too sure it makes any sense the way it came out ;-) But I'm sure you follow me.

What I propose:

-) File precedence: ${prefix}/etc/ports/ports.conf (note, we should update that to ${prefix}/etc/MacPorts for consistency's sake while at it!), ~/.macports/ports.conf, env PORTSRC variable (or however it's called). Last one found wins;

-) A value found in file 2 overrides the same value found in file 1, and the same in file 3 overrides the one in file 2, etc (only values, not entire files);

-) ~/.macports/user.conf is kept solely for user information with respect to mpwa;

-) Maybe we could also include support for ~/.macports/ variants.conf and also, why not, an env variable for it;

-) How about also an equivalent env variable for ~/.macports/ user.conf? Consistency is a big plus!

Thoughts?

My thought is that it works fine right now. It's not my top priority to beat this very minor piece of functionality to death. My original mail was just to make sure I let people know that I changed the name/ location of a file that nobody probably uses. It was not an attempt to spend a bunch of time and energy to rethink preferences ;) James