Dan Price wrote:
> On Wed 08 Oct 2008 at 02:12PM, Shawn Walker wrote:
>> [EMAIL PROTECTED] wrote:
>>>> I wasn't aware that pkg.client was considered the exclusive domain of 
>>>> the cli given that much of it's code is shared.
>>> Last time I checked, client.py was the CLI.  Did you mean you wanted the
>>> code to live somewhere in modules/client?
>> Yes, as in the pkg.client module (e.g. "import pkg.client") :)
>>
>>>> If your concern is about crossing boundaries, then it should be put into 
>>>> the API.
>>> I'm not sure these environment variables need to be exposed to the front
>>> ends through an API.  It would make more sense to have
>>> socket.defaulttimeout and max_timeouts live behind the API for the front
>>> ends.  The fact that they're currently exposed is a historical artifact
>>> of our ad-hoc development process, not an indication of overall design
>>> goals.
>> Ah, I had thought it was intentional that we exposed them.  In that 
>> case, I'd agree with your sentiment of putting them into new, public 
>> client API Brock wrote.
> 
> I agree that:
>         - We should have someplace better than misc to store global settings
>         - We should centralize env variable processing
> 
> However, I can't fix all of this today and get all of the other stuff I
> need to do done before vacation-- refactoring is just too slow and
> painful in python to be able to do this rapidly.  I am leaving this as
> is for now, and will make improvements when I return.
> 
> Unless people object (in which case this wad will have to be
> shelved for a couple of weeks).   I will get a bug filed before I
> integrate to note these desired improvements.

As long as there's a bug filed for now, I'm happy...

The benefits the improvements bring outweigh my unhappiness regarding 
the placement.

Cheers,
-- 
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to