[Dev] application.Util.py status

[John Anderson]

After struggling with the Util.py issue I decided to make it part of 
docgen, so I moved it to docgen. Here's why:

It's only used by docgen, which is a developer tool, not part of the 
Chandler application. Also unit tests are not part of the Application.

Application.py's opening of the repository is beginning to be too 
complicated than is necessary for unit tests or docgen. Trying to share 
this code with unit tests or docgen makes it harder to change without 
the risk of breaking unit tests or Chandler.

The Notification manager, and its initialization, is going away, further 
simplifying Util.py

All the unit tests use RepositoryTestCase to open the repository, which 
seems adequate for their needs, and if it isn't, opening the repository 
is pretty simple and we already have an api for that, so adding another 
api to open a repository on top of our existing api doesn't seem like 
it's the right thing to do -- instead it make more sense to improve the 
existing api.

There are enough other things that unit tests might want to initialize, 
that doing them in a way they could be shared with Application.py didn't 
seem obvious and following this strategy leads to writing code that 
isn't used now, but might be used in the future -- premature generalization.

John

John Anderson wrote:

> 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
>>
>>
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev