Re: PATCHES: more refactoring and skeletal cvs2hg

Greg Ward wrote:
> On Mon, Aug 31, 2009 at 4:38 AM, Michael Haggerty<[email protected]> wrote:
>>> Hmmm.  IMHO the duplication between cvs2{svn,git,hg,bzr} is worse than
>>> the duplication in main.py.
>> I don't mind the duplication in main.py, which is really quite minimal.
>>  What I would like to avoid is that cvs2xxx has to import code that is
>> only useful for cvs2yyy.  Currently, all scripts import main.py, and
>> main unconditionally imports svn_run_options, git_run_options, and
>> bzr_run_options, which probably import lots more junk that is
>> backend-specific.
> 
> Yes.  Note that hg_main() does things differently:
> 
> def hg_main(progname, cmd_args):
>   # Import late so cvs2{svn,git} do not depend on being able to import
>   # the Mercurial API.
>   from cvs2svn_lib.hg_run_options import HgRunOptions
> 
> Moving each main() to *_run_options.py might complicate that slightly.
>  Would not be difficult to overcome, though; it's only the import of
> hg_output_option that needs to be delayed, because that's where the
> "import mercurial" happens.

I don't understand the problem.  If hg_main() is defined within
hg_run_options.py, and the latter imports the Mercurial API as a
file-level import, then cvs2hg only needs to import hg_run_options.py.
The other cvs2xxx scripts don't need to import (or even know about)
hg_run_options.py so they won't have any import problems.

But you don't have to worry about this.  I'll look at it again after you
have submitted more of your code.

>> I suppose we could have a python_version_check.py module, import it from
>> each of the main scripts, then call
>> python_version_check.check_version(progname).  I don't think we want to
>> move this check to main.py, though, because it has to be loadable from
>> the widest possible range of Python versions.
> 
> Why not just put it in cvs2svn_lib/__init__.py?  That would enable a
> fairly simple idiom:
> 
>   import cvs2svn_lib
>   cvs2svn_lib.check_python_version()
> 
> which could be the same in each cvs2* script as well as run-tests.py.
> That means __init__.py must be tiny and compatible with everything
> from 1.5.2 to 3.1, which I *think* is possible.

If were were willing to forgo the name of the script in the error
messages, then we could put the whole test inline in __init__.py.  Since
__init__.py is always executed before importing any other modules in the
package, this would guard all cvs2svn_lib modules without the importing
module having to do anything special.

But again, this is not urgent.

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2388955

To unsubscribe from this discussion, e-mail: [[email protected]].