On Wed, Feb 2, 2011 at 2:46 PM, Hartmut Goebel
<h.goe...@goebel-consult.de>wrote:
> [...]
> > no more no less.
>
> I propose going a little bit further and sorting the modules into
> subpackages. Something like
>
> shinken/core/...
> shinken/arbiter/...
>
> This structure would help developers to understand the code better. And
> if necessary for somebody, he could build deployment packages containing
> only the parts required (e.g. the poller).
>
> Taking this one step further, the "shinken" package could become a
> namespace package (see
> <http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages>).
> So
> the Plugin-stuff, I'm working on could go into a namespaced package
> shinken.plugins.core and plugin implementations into packages like
> shinken.plugins.check_fs_ping. (Just an idea yet. I'm not going to
> implementent this now.)
>
> [...]
Hi,
Why not, but it will complexify the import pass (not a huge problem) and
sys.path management (more buggy part) a lot if there are too much of them.
It should be easier to read too. What cut do you propose exactly?
Jean
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
