"outdated" and similar actions broken in trunk's port.tcl, a possible fix

[Juan Manuel Palacios]

	Hi guys!

	I'm putting together a patch to fix the regression experienced in  
trunk's port.tcl after the recent API tweaks to macports1.0. As it  
turns out, many actions (installed, outdated, search and others) are  
currently broken because the "ports_no_args" flag in the  
"global_options" array is not being reached; but all in all, I feel  
this is more of a symptom of a general mix-up in port.tcl's two main  
global arrays that was revealed by the API changes rather than plain  
breakage, and I believe the appropriate fix is to clean the mess-up  
altogether.

	Basically, port.tcl has two main global arrays:

1) ui_options, for storing user interface options like verbose/debug/ 
quiet (but also some other things I believe do not belong in it),  
passed to macports1.0;
2) global_options, for storing all sorts mixed-up things (read  
below), passed to macports1.0 too;
3) (there's also global_variations, but I think that's orthogonal to  
the issue at hand).

	The breakage occurs because at the time the "global_options" array  
is passed to macports1.0, "ports_no_args" hasn't been set yet;  
subsequently, "[macports:global_option_isset ports_no_args]" is used  
to determine the behavior of the outdated/installed/search/etc  
actions and as the flag is not yet set, things naturally break.

	As Kevin noted recently, port.tcl stores options that are "private"  
to port.tcl and options that are passed to the macports1.0 layer  
*both* inside the global_options array, and I believe the proper fix  
is to split these two types into their own properly named arrays.

	In my ongoing patch I created a "private_options" global array in  
which I store flags like "ports_no_args" and managed to recover some  
of the broken functionality by polling the former for the latter flag  
(through [info exists private_options(ports_no_args)]), rather than  
using the now in macports1.0 "global_option_isset" proc on the  
"global_options" array (which does not contain the needed flag). So  
to me this is an obvious example of what should be an option  
*private* to port.tcl, candidate for storing inside "private_options".

	In order to complete the patch I would need to know exactly what  
options are private and which ones should be passed to macports1.0  
through "global_options". Polling the appropriate array throughout  
port.tcl will not only recover all the broken functionality but also  
clear up any confusion as to what stays and what is handed over.

	Global options that should be passed to macports1.0 are, I think:

*) 'ports_force', port(1)'s -f;
*) 'ports_ignore_older', port(1)'s -o;
*) 'ports_nodeps', port(1)'s -n;
*) 'port_uninstall_old', port(1)'s -u;
*) 'ports_do_dependents', port(1)'s -R;
*) 'ports_source_only', port(1)'s -s;
*) 'ports_binary_only', port(1)'s -b;
*) 'ports_autoclean', port(1)'s -c & -k;
*) 'ports_trace', port(1)'s -t;

	Am I right? Did I miss any? Or am I, instead, including some options  
that don't need to be passed to macports1.0?

	Conversely, options that are private to port.tcl are:

*) ports_no_args, currently being stored in global_options but opting  
for private_options, I believe;
*) I'm sure I'm missing others throughout port.tcl that are really of  
private scope and need not be stored in global_options; care to  
illuminate?

	Thirdly, options I'm not sure about where they should be:

*) long arguments processed in the "parse_options" proc, which are  
being stored in "global_options". Do they need to stay there or can  
they be moved to the private array? Or maybe split between the two?
*) 'ports_commandfiles' in the "parse_options" proc too, why is it  
being saved in ui_options? What does it have to do with the user  
interface? Seems to me like this is another perfect candidate for the  
private_options array (and in lack of it, I would have imagined this  
option is more appropriate for saving inside the global_options  
array, not in ui_options);
*) 'ports_processall', same comments as above;
*) 'ports_exit', ditto;

	So as you can see, even though a quick fix for this regression could  
be a very simple patch (which I could commit like *now*), what I  
think is the proper one gets a bit more involved. After knowing all  
the information I request above, the final part to call the fix  
complete is knowing in what situations I would need to poll the  
"global_options" array and/or "private_options". As the code stands  
now, many constructs simply [array get global_options] and thus  
obtain all the baggage that's stored there (I'm sure sometimes  
unnecessarily so), but that would naturally need to change if we do  
split the options (including some proc prototypes).

	So... can more port.tcl illuminated souls shine some light on me? ;-)

	Thanks for even reading all this mail this far! Regards,...


-jmpp


PS; The patch I'm working on is attached in its current, still  
incipient form. If you're careful you'll also notice the removal of  
some global calls in some procs, which are due to the API changes to  
macpors1.0 (the corresponding vars need no longer be brought into  
scope).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: port.tcl.diff
Type: application/octet-stream
Size: 7912 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071016/5b0bea58/port.tcl-0001.obj
-------------- next part --------------