> Does this capture what is wrong with the current system?
I started to look at a possible exception on 'make.py', but you are
right I should rather make a custom builder for lxml addon, exception
might be for the 'build all' argument (make.py) when matching 'lxml' addon!
I should be able to do that.
It could be close to what I already did for 'po/update_po.py' on trunk!
> Anything else?
> lxml in 3.4 requires special build handling
Yes, this gramplet is already ignored by listing files (feature added by
you on 3.4), but it seems that it is also no more possible to install a
downloaded addon (tgz files) via Gramps (plugins manager)!
It should be minor because, even stable, this gramplet is for testing,
having a sample of Gramps XML handling with lxml lib, an experimental
Gramps XML validator, a possible quick XML dump, and also a quick way
for transforming our data without advanced coding. I do not think this
addon is for an every day use. It will be still experimental.
So, the download is possible, but as you write, it requires something
special for building because it also needs specific files.
PS1: about the lxml gramplet itself, there one/two limitations:
1. cannot parse a Gramps XML file more that one time during the session
2. buffer/cache limitations; I guess like most mobile applications or
local scripts: slow down when I display more than 2/3Mo of XML data (raw
- plain text).
PS2: the Gramps XML validation/parsing via lxml is very sensible
(related to C language?). ie, pass it all or a nothing
Doug Blank a écrit :
> (None of this is necessary for Gramps 3.4, but for new features for a
> future build system for Addons. Although lxml in 3.4 requires special
> build handling; see below if interested.)
> I'm sure that there could be better ways of handling Addons rather
> than using make.py. Background: Currently, make.py does a few things:
> it does some clever translation merging to minimize the work for
> translators (eg, it looks in other addons and gramps for any existing
> translations), builds the tgz files for download, and builds the
> listing files in each language.
> But, make.py doesn't have to do everything for an addon: you could
> have additional tools that build the things that make.py needs.
> For example, your latest commit says that "lxml addon needs some
> non-python and non-xml files: css, xsl, dtd, rng; need to find a way
> via make.py". But as long as you create (and add to svn) the necessary
> files in po and locale, you can do that in contrib/lxml through
> whatever mechanism you want (Makefile, setup.py, etc).
> Also note that you can include files in the tgz file by listing them
> when you build the addon. But there are some limitations:
> 1) Can't build the addons on a system that doesn't have the standard
> Linux tools (eg, Windows)
> 2) When you "build all" (or "build AddonName") it doesn't know any
> specifics (eg, such as that outlined above)
> I'm not too concerned about (1) (but others are free to come up with
> something better). (2) could be fixed by looking for, and calling, a
> default addon-specific build command (for example, looking for a
> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest").
> Currently when you "build all" or "build lxml" it will not build all
> that needs building, nor include all of the relevant files (right?).
> Does this capture what is wrong with the current system? Anything else?
> On Sat, May 5, 2012 at 4:01 AM, Jérôme <romjerome@...> wrote:
>> No problem, but only few like bug #5702 , which is a 'addon' issue.
>> There is a custom use of gettext domain under some locales with
>> available translations for addons, see TransUtils module:
>> def get_addon_translator(filename=None, domain="addon", languages=None):
>> Get a translator for an addon.
>> filename - filename of a file in directory with full path, or
>> None to get from running code
>> domain - the name of the .mo file under the LANG/LC_MESSAGES dir
>> languages - a list of languages to force
>> returns - a gettext.translation object
>> _ = get_addon_translator(languages=["fr_BE.utf8"]).gettext
>> The return object has the following properties and methods:
>> Assumes path/filename
>> The 'make.py' is a python script used for handling addons (packaging,
>> listing files, translations, init, etc ...). I just thought on
>> alternative script: nothing related to setup alternative (Makefile) for
>> Gramps itself!
>> My guess was for few minor issues remaining on Addon environment (not
>> only for 3.4).
>> Is markup for Gtkbuilder domain (.glade) properly set for addons?
>> Ot is there any encoding issue related to markup and .glade file?
>> ex: PlaceCompletion addon
>> 'make.py' is a CLI handler but I suppose designed for linux (shell,
>> paths to programs used by script).
>> It is more global, something like described into article "The benefits
>> of open source"  --George Wright March 25, 2012
>>> "Systems are more than the sum of their component parts, if using a free library gets you the functionality that you need and as long as you comply with the licence, it makes good sense. Why reinvent the wheel and forgo what is sometimes years of community development and testing?
>>> This is not a free software free pass, every business should evaluate the pros and cons of each library or subsystem in light of their needs but to exclude potential solutions because of the free software/open sources stigma is blindness. There are legal implications if you decide to extend these libraries, but it is nowhere near as problematic as often made out."
>> Current addons handling for Gramps sounds like having servers with a
>> centralized translation handler/platform, like pootle, transifex,
>> launchpad, etc ... associated with a repository (like mobile
>> Here, Doug has generated something close to an addon SDK, making
>> handling easier for people familiar with free library.
>> These free ressources/logic_ways used by 'make.py' rather mean
>> 'accessible' and 'fast' handling with few efforts (if you are familiar
>> with linux usage...).
>> Translators contributions is growing with gramps project.
>> eg, *.po files is like main Gramps' API (gen.lib): flexible and
>> independant data/libs!
>> The gramps' ecosystem is powerful but *if* we can spend less time on
>> maintenance this may be also greater, even it is not perfect (ex: cannot
>> use all features provided by/via 'make.py', under Windows platform).
>> It is behind a request for more platforms support, a specific SDK for
>> addons, to still have something fast and flexible, to provide
>> documentation for next developement and needs.
>> I do not like the logic which often forget maintenance
>> (ex: market activity and minor update/developement wanted by the user:
>> iOS, Androïd, Windows, Ubuntu ...)
>> As said before, it was a good surprise to see some alternate release
>> like done by community/user. ex: gramps build service on OpenSuse
>> It is just how I see addons handling!
>>  http://translate.sourceforge.net/wiki/pootle
>>  https://www.transifex.net/
>> Tim Lyons a écrit :
>>> On 4 May 2012, at 19:46, Jérôme wrote:
>>>> DeepConnectionsGramplet is an addon.
>>> Since DeepConnections gramplet is an addon, it has no impact on the
>>> timing of the 3.4 release (nor on the completeness of the roadmap).
>>>> Gramps is looking at multiple locations/domains for addons.
>>> I have updated the addons page here:
>>> to describe how gramps 3.4 looks for addons. It no longer looks in two
>>> places. The addons are installed through the Preferences dialogue
>>> (except for some which are installed manually).
>>>> Yes, there is still some minor translation issues (PlaceCompletion or
>>>> domain with strings using markup into a .glade file ? , hardcoded
>>> The problem I was having with translations is described below. For me
>>> 'make install' is installing the translation files in
>>> /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, but Gramps is not
>>> looking there for the files. Maybe it is looking in
>>> /usr/local/share/locale, which is where the wiki says the files are.
>>> Am I doing something wrong (because I do not usually use the
>>> translations)? If there is a real problem here, then it needs to be
>>> resolved before the release.
>>>> And I wanted to try to generate an alternative to current 'make.py' by
>>>> or 'argparse'
>>>> Anyway, this is not specific to 3.4!
>>> Yes, let's ignore alternatives to make, because they are not relevant to
>>> the 3.4.0 release. (Rob is working on this under GEPS026 in the GEPS026
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
>>> latest in malware threats.
>>> Gramps-devel mailing list
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> Gramps-devel mailing list