BIND 10 #1243: stats test shouldn't have its own "isc" packages

[BIND 10 Development]

#1243: stats test shouldn't have its own "isc" packages
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  major         |                    Milestone:  Next-
           Component:  statistics    |  Sprint-Proposed
           Sensitive:  0             |                     Keywords:
         Sub-Project:  Core          |              Defect Severity:  High
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 There's a directory src/bin/stats/tests/isc, and some forked
 versions of "isc" python packages (cc, config, log, util) are defined
 beneath it.

 IMO, this is a very bad approach.

 First off, this is very confusing.  Unless you know the trick
 beforehand, you'll easily encounter a strange failure in importing an
 isc python package, and it would take long time to identify the cause.

 Second, obviously, this approach isn't scalable and easily leads to
 duplicate efforts.  Every time we develop a new python package or
 library on which the stats or its test depends, either directly or
 indirectly, you'll need to make a copy or forwarder under its forked
 version.  In fact, there's already a complete copy of
 isc/log/__init__.py (imagine what happens when the original changes),
 and a nullified version of isc/util/process.py (imagine this file
 contains 100 methods).

 If I understand the intent correctly, the forked packages are to
 define some mock classes to replace modules that are not easy to use
 under the test environment (like ccsession, which would need network
 communication).  Python should already be flexible enough to allow
 such on-the-fly replacement without using an ugly overriding like
 this.  Please seriously reconsider an alternative that would eliminate
 the forked isc packages.

 Sooner is better, so I suggest this to be included in the next sprint.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1243>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development