[Dev] application.Util.py status

[John Anderson]

I'm thinking of having a module equivalent to Util.py so unit tests 
don't need to include code to open the repository, but the applicaiton's 
opening of the repository is getting more complicated -- and different 
-- from that used by the unit tests.

Morgen Sagen wrote:

> 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
>
>