2009/4/29 Michael DeHaan <mdehaan(a)redhat.com>:
> Max Spevack wrote:
>
>> On Tue, 28 Apr 2009, Yaakov Nemoy wrote:
>>
>>
>>
>>> #1 works because there's a precedent that applications that are really
>>> just entrypoints into python library code should be named like a
>>> library. If nothing else, there would be a definite 'python-ekg'
>>> package no matter what. I could split it off with subpackages too.
>>>
>>>
>> I guess that's ok with me. No strong feelings either way.
>>
>> --Max
>> _______________________________________________
>> ekg mailing list
>> ekg(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/ekg
>>
>>
> ekg is meant to be a tool, not a library.
>
> We do not, for instance, call things fooapp-java when they are
> applications, as end users don't care.
>
> ekg-scanner is a better choice, as it says what it does.
>
> It is not true that an application should have a seperate package for
> it's library bits, no matter what, that should only happen
> if there is a need for other applications/packages to use that tool
> without installing the rest of the application. So far, that's not the case.
>
One of the weird things i've found in programming is that even though
you have a 'tool' to do foo, you never know how someone else might
want to use it as well. Some of the best tools i work with open up the
basic building blocks to make it easier to make other tools that
interoperate with it. Here's how this logic applies to EKG.
The data model is just a generic way of storing and updating certain
kinds of information. Some parts of it actually would be better off as
an SQLAlchemy extension. If someone were to think up another analysis,
i think they would be best off including the following code in their
program:
from ekg.model import *
This is far better than having to rip open a few shell scripts written
in python.
The analysis part is also very general purpose, and the more general
purpose, the better. Again, someone may want to use the same analysis
on different data.
Right now, visualizations are lacking and the application is not even
running regular reports.
I think how it's packaged is not our major concern until we get feature
parity with v2.
--Michael