health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] Error after installation of language pack


From: Axel Braun
Subject: Re: [Health-dev] Error after installation of language pack
Date: Mon, 02 Mar 2020 19:42:29 +0100

Hi Luis,

Am Sonntag, 1. März 2020, 21:06:27 CET schrieb Luis Falcon:
 
> On Sun, 1 Mar 2020 13:58:31 +0100
> 
> "Axel Braun" <address@hidden> wrote:
> > Dear GNU Health hackers,
> > 
> > here is something to test.
> > 
> > Setup of a new, clean GH installation, with new database:
> > 
> > 
> > /tmp/de.zip
> > 100%[==================================================================>]
> > 
> >   4,13M  2,07MB/s    in 2,0s
> > 
> > 2020-02-28 18:41:01 [INFO] Installing / Updating language files for
> > de ... 2020-02-28 18:41:01 [INFO] Language pack de sucessfully
> > installed / updated 2020-02-28 18:41:01 [INFO] You now need to update
> > the database modules
> 
> Language packages should not affect that issue. (they only include .po
> files, not .cfg)
> 
> > file_open raise IOError('File not found : %s ' % name) OSError: File
> >
> > not found :
> >/usr/lib/python3.6/site-packages/trytond/modules/health_caldav/tryton.cfg
> >
> > -> translation is in directory health_calendar instead of calendar
> > (same for health_webdav3_server and webdav)
> 
> That is correct. For backward compatibility, the package (modules)
> names are still "calendar" and "webdav", although they point to the
> corresponding health packages. This has been like this for years now.

This is correct, the the previous versions of GH contained these direcotries 
(and still do)
 
> So, under trytond/modules, the following links should exist:
> 
> calendar -> ~gnuhealth/tryton/server/modules/health_caldav
> 
> webdav -> ~gnuhealth/tryton/server/modules/health_webdav3_server

If you are using solely the information from the setup.py files, this 
information is not available .

> If you are using the package-based installation, take a close look at
> how the setup.py of each package. For instance, let's look at the
> health_caldav package:
> 
> ** health_caldav package**.
> The "package_dir"  and "package_data" variables point to
> trytond.modules.calendar.
> 
> package_dir={'trytond.modules.calendar': '.'},

Correct, it points to calendar, and not to health_caldav

> and
> 
> package_data={
>         'trytond.modules.calendar': (info.get('xml', [])
>             + ['tryton.cfg', 'view/*.xml', 'locale/*.po']),
> 
> 
> Notice that it uses the "calendar" dir, which is linked to the
> health_caldav.
> 
> In other words, if you have the link in place, then everything will be
> OK. The vanilla version does it. You can safely do the link, since
> these are now GH packages only. No need to change anything on setup.py.

Mixing up two different directory structures is IMO nt a good idea. That you 
could fix this with a link is nice, but a packager can just use the 
information that is available in setup, and there it is not existant.

The better approach would have been to migrate everything to a new structure 
at a certain pont in time

> Again, this is for backward compatibility with the original tryton
> packages. For the upcoming GH version, we will have a script that
> renames the module name at db level before the upgrade and everything
> should be unified. But it has been like this for the last 3 years.

Will try this, thanks
Axel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]