[Dev] application.Util.py status

[Morgen Sagen]

If the procedures for creating/opening a repository, loading repository  
packs, and loading parcels are actually different when you are running  
Chandler versus an external script (unit test, schema documentation  
generator, etc.), then by all means let's not have Application.py try  
to use Util.py.  But if we get rid of Util.py, then each of these  
external scripts has to recreate that basic startup code. So I am still  
in favor for having some module equivalent to Util.py for use by  
external scripts.

~morgen

On Dec 10, 2004, at 9:48 AM, John Anderson wrote:

> Hi Mike:
>
> I'm now considering getting rid of Util.py since it looks more and  
> more like the application specific code is diverging from the unit  
> test specific code -- but I still need to look into it some more. I'll  
> keep you posted.
>
> I'm curious to know what features your command line processing isn't  
> handled by Application.py today. I was hoping that we don't have to  
> make the command line processing too complicated, and today it's  
> already very complicated.
>
> John
>
> Mike Taylor wrote:
>
>> John,
>>
>> One of the motivating factors for me to suggest placing the option   
>> parsing routine into Util.py is that I envision that it will be  
>> mostly  helper code to load values from the four possible sources:   
>> default  base values, chandler config file, environment variables  
>> and/or command  line values.  All of the decisions based on the  
>> values should continue  to be in Application.py -- sorry if I didn't  
>> make that clear in my  original post.
>>
>> I have a nice helper routine that I've used in my other python  
>> projects  that takes a number of dictionaries and returns a  
>> dictionary of values  so the messy stuff is nicely tucked away and  
>> Application.py doesn't get  bloated.
>>
>> ---
>> Bear
>> http://code-bear.com
>> PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29
>>
>>
>> On Dec 8, 2004, at 12:06 PM, John Anderson wrote:
>>
>>> Startup option parsing should probably go in Application.py if it's   
>>> part of Chandler startup.
>>>
>>> The startup stuff in Util.py is there only for unit tests, and I  
>>> need  to make a pass to simplify it and modify Application.py to  
>>> also use  it. I'll try to do it soon.
>>>
>>> Also, I'd be happy to review any changes you make to Application.py,  
>>>  since I wrote most of it.
>>>
>>> John
>>>
>>> Mike Taylor wrote:
>>>
>>>> I'm going thru the Chandler startup process to see what is new and  
>>>> I  have a question :)
>>>>
>>>> The routines in application/Util.py seem to be duplicated by code   
>>>> inside of application/Application.py - is there a migration in   
>>>> progress *to* Util.py or ???
>>>>
>>>> If it's not a migration, then is there a need for Util.py.  Should  
>>>> I  start looking into finishing the migration if it is?
>>>>
>>>> The reason for me doing this is that I need to add some startup   
>>>> option parsing code to allow me to continue with the linux  
>>>> installer  and, while scouting the best place for the new code, I  
>>>> came across  Util.py which seems to be a good spot for the code.
>>>>
>>>> ---
>>>> Bear
>>>> http://code-bear.com
>>>> PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29
>>>>
>>>> -------------------------------------------------------------------- 
>>>> -- --
>>>>
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>> Open Source Applications Foundation "Dev" mailing list
>>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev