[et-mgmt-tools] [RFC] Approach to installing a localized virtinst

Daniel P. Berrange berrange at redhat.com
Fri Jun 29 12:59:56 UTC 2007

On Thu, Jun 28, 2007 at 02:44:29PM -0400, Cole Robinson wrote:
> Hello all,
> I've recently undertaken adding localization support to virtinst. Since 
> currently build and install from source is done using a typical setup.py 
> script, I've encountered several issues involving how to handle 
> installing the locale files, and making virtinst aware of where they are.
> The attached patch handles the first issue: I added custom functionality 
> to to the build and install_data commands as invoked in the setup 
> script. The build command searchs po/ for any .po files and invokes 
> msgfmt to compile them. The install_data additions have to do some silly 
>  things to name the files correctly as distutils cannot rename extra 
> install files on the fly (ex. moves po/es.mo to build/es/virtinst.mo).
> The second problem is a bit more perplexing. The path to the locale 
> files has to be placed into a virtinst header so that the library knows 
> where to look for them. Possible solutions I see:
> 1) Extracting the install root from setup.py mid run. This has to happen 
> after build but before actual install. The locale path could then be 
> formed and sed'd or some equivalent into a virtinst header file, which 
> would than have to be (re)compiled and moved to the build directory. 
> Ugly way to do it, but the user can still use setup.py as normal and all 
> should work.

I think since your example for installing .po files is already overriding
the install_data class, we might as well override the install_lib class
and substitute in the local directory path at that point.

> Thoughts? I'm not too familiar with this stuff so I may be overlooking a 
> simpler solution, or oversimplifying a complex one!

Python's distutils is pretty horribly limited compared to comparable
tools, so I think overloading the install_lib is easiest option, unless
we were to throw out distutils completely which isn't exactly easy either. 

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

More information about the et-mgmt-tools mailing list