El 23/12/2012 02:22 p.m., Cédric Krier escribió:
On 23/12/12 13:00 -0500, Odicha wrote:
El 23/12/2012 12:48 p.m., Cédric Krier escribió:
On 23/12/12 12:02 -0500, Odicha wrote:
I think the best approach for this is add some extra config value,
something like LIBREOFFICE_PATH so it could be parsed if trytond is
running on a win32 box. I'll open an issue, but I'd like to know
what do you think before writing a patch.
I could be something like:
if sys.platform == "win32":
cmd= ['%s' % CONFIG['libreoffice_path.......
For me, it is windows who sucks and we should not hack Tryton for that.
A simple solution is to put a "unoconv" executable in the current
directory.
Sure it sucks. But if you don't want "to freeze" it and work with it
as a framework, make unoconv executable is not perhaps the best
answer.
I really don't understand your point.
Tryton just requires to have unoconv command working but as Windows only
recognize .exe or .bat as executable, just make one for unoconv.
More over, in some way the issue should be reported to unoconv project
to provide the right script to run on Windows.
https://github.com/dagwieers/unoconv/issues/112
I think it's better making some small hacks & running tryton +
gnuhealth in windows
No, we build a framework and it doesn't build on top of hacks.
than porting gnu health code to openerp because
you can not run a linux server instead a win32 one. (it's only an
example)
This kind on argument doesn't work here.
It doesn't work here because people goes another places :) I'll mantain
my own code branch then. (built on top of hacks)
--
--
[email protected] mailing list
