From: Peter L. <pet...@te...> - 2014-06-04 14:23:16
|
Devs, Should gramps 4.1.0 and gramps master share the same gramps.ini file? /Peter -- Peter Landgren Talken Hagen 671 94 Brunskog 0570-530 21 070-345 0964 |
From: John R. <jr...@ce...> - 2014-06-05 00:36:46
|
On Jun 4, 2014, at 7:23 AM, Peter Landgren wrote: > Devs, > > Should gramps 4.1.0 and gramps master share the same gramps.ini file? Right now it doesn't matter because master won't have diverged much. In the longer run, of course not; otherwise there can be no changes in master that would make the .ini file incompatible with gramps41. Regards, John Ralls |
From: Paul F. <pf....@gm...> - 2014-06-10 15:32:58
|
On 6/4/14, Peter Landgren <pet...@te...> wrote: > Should gramps 4.1.0 and gramps master share the same gramps.ini file? I have changed version.py in trunk/master to 4.2.0. |
From: Paul F. <pf....@gm...> - 2014-06-11 17:43:50
|
On 6/10/14, Paul Franklin <pf....@gm...> wrote: > On 6/4/14, Peter Landgren <pet...@te...> wrote: >> Should gramps 4.1.0 and gramps master share the same gramps.ini file? > > I have changed version.py in trunk/master to 4.2.0. > I have reverted that change, back to 4.1.0, since there are more things which are required and I don't have time now. For instance changing every *.gpr.py file in gramps to also have 4.2, as well as making a new branch in the addons repository for the third-party plugins. And as John said, it isn't very critical right now. We all have other things which are more urgent, I would guess. FYI. |
From: Jerome <rom...@ya...> - 2014-06-16 15:09:12
|
Devs, Code keeps some "gramps version" references. Most on urls for help or some warning messages. I tried to limit this usage on master. It is not perfect, like before, but it should avoid mixup with version numbers. There is also a possible change which calls constant too: eg, --- a/gramps/plugins/gramplet/gramplet.gpr.py +++ b/gramps/plugins/gramplet/gramplet.gpr.py @@ -29,6 +29,7 @@ from gramps.gen.const import GRAMPS_LOCALE as glocale _ = glocale.translation.sgettext +from gramps.version import major_version #------------------------------------------------------------------------ # @@ -40,7 +41,7 @@ register(GRAMPLET, name=_("Age on Date"), description = _("Gramplet showing ages of living people on a specific date"), version="2.0.0", - gramps_target_version="4.1", + gramps_target_version = major_version, status = STABLE, fname="ageondategramplet.py", height=200, @@ -61,7 +62,7 @@ register(GRAMPLET, detached_width = 600, detached_height = 450, version="1.0.0", - gramps_target_version="4.1", + gramps_target_version = major_version, ) register(GRAMPLET, @@ -74,7 +75,7 @@ register(GRAMPLET, gramplet = 'CalendarGramplet', gramplet_title=_("Calendar"), version="1.0.0", - gramps_target_version="4.1", + gramps_target_version = major_version, etc ... The problem is that this change will allow to run these plugins with all versions of gramps! So, this type of change might be useful for migration to a next major version, but it is also wrong on the way used. :( Is there a quick solution for migrating gramps_target_version to "4.2"? Jérôme. Le mer. 11 juin 2014 at 19:43, Paul Franklin <pf....@gm...> a écrit : > On 6/10/14, Paul Franklin <pf....@gm...> wrote: >> On 6/4/14, Peter Landgren <pet...@te...> wrote: >>> Should gramps 4.1.0 and gramps master share the same gramps.ini >>> file? >>> >> I have changed version.py in trunk/master to 4.2.0. >> >> > I have reverted that change, back to 4.1.0, since there are > more things which are required and I don't have time now. > > For instance changing every *.gpr.py file in gramps to also > have 4.2, as well as making a new branch in the addons > repository for the third-party plugins. > > And as John said, it isn't very critical right now. We all > have other things which are more urgent, I would guess. > > FYI. > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk > Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <ni...@gr...> - 2014-06-16 16:31:05
|
On 16/06/14 16:07, Jerome wrote: > Is there a quick solution for migrating gramps_target_version to "4.2"? > I would probably use sed to make the change to all gpr files. Do you want me to make the change for you? Nick. |
From: Paul F. <pf....@gm...> - 2014-06-16 15:48:49
|
On 6/16/14, Jerome <rom...@ya...> wrote: > Is there a quick solution for migrating gramps_target_version to "4.2"? I will be happy to change version.py (from the 4.1.99 you made it) to 4.2.0, and to change every trunk/master *.gpy.py file to say "4.2" instead of the "4.1" they say now. I can do it in am hour or two. Is that "quick" enough? 8-) I don't want to touch the gramps-addons repo however. Somebody else will have to make a gramps41 branch there, and update its trunk to 4.2 -- or whatever is needed there. Also, earlier today you made this change in gramps/gui/grampsgui.py: - _("This Gramps 4.1-trunk is a development release. " + _("This Gramps master is a development release. " and I suggest the second line should instead be something like: + _("This Gramps \('master'\) is a development release. " with the single-quote marks around the "master" inside the parens. |
From: John R. <jr...@ce...> - 2014-06-16 16:21:24
|
On 16 Jun 2014, at 08:07, Jerome <rom...@ya...> wrote: > Devs, > > Code keeps some "gramps version" references. > Most on urls for help or some warning messages. > > I tried to limit this usage on master. > It is not perfect, like before, but it should avoid mixup with version numbers. > > There is also a possible change which calls constant too: > > eg, > --- a/gramps/plugins/gramplet/gramplet.gpr.py > +++ b/gramps/plugins/gramplet/gramplet.gpr.py > @@ -29,6 +29,7 @@ > > from gramps.gen.const import GRAMPS_LOCALE as glocale > _ = glocale.translation.sgettext > +from gramps.version import major_version > > #------------------------------------------------------------------------ > # > @@ -40,7 +41,7 @@ register(GRAMPLET, > name=_("Age on Date"), > description = _("Gramplet showing ages of living people on a specific date"), > version="2.0.0", > - gramps_target_version="4.1", > + gramps_target_version = major_version, > status = STABLE, > fname="ageondategramplet.py", > height=200, > @@ -61,7 +62,7 @@ register(GRAMPLET, > detached_width = 600, > detached_height = 450, > version="1.0.0", > - gramps_target_version="4.1", > + gramps_target_version = major_version, > ) > > register(GRAMPLET, > @@ -74,7 +75,7 @@ register(GRAMPLET, > gramplet = 'CalendarGramplet', > gramplet_title=_("Calendar"), > version="1.0.0", > - gramps_target_version="4.1", > + gramps_target_version = major_version, > > etc ... > > The problem is that this change will allow to run these plugins with all versions of gramps! So, this type of change might be useful for migration to a next major version, but it is also wrong on the way used. :( > > Is there a quick solution for migrating gramps_target_version to "4.2"? find contrib -name *.gpr.py -exec sed -i '' -e s/gramps_target_version=4.1/gramps_target_version=4.2/ {} \; N.B that's two single quotes after the -i. Regards, John Ralls |
From: Jerome <rom...@ya...> - 2014-06-16 17:05:16
|
Thanks! The first part works fine. eg, $ find gramps/plugins/* -name *.gpr.py but on the second part, sed cannot read these files under my config! Regards, Jérôme Le lun. 16 juin 2014 at 18:21, John Ralls <jr...@ce...> a écrit : >> >> Is there a quick solution for migrating gramps_target_version to >> "4.2"? >> > find contrib -name *.gpr.py -exec sed -i '' -e > s/gramps_target_version=4.1/gramps_target_version=4.2/ {} \; > > N.B that's two single quotes after the -i. > > Regards, > John Ralls > > |
From: John R. <jr...@ce...> - 2014-06-16 17:23:58
|
On 16 Jun 2014, at 10:03, Jerome <rom...@ya...> wrote: > Thanks! > > The first part works fine. > > eg, > > $ find gramps/plugins/* -name *.gpr.py > > but on the second part, sed cannot read these files under my config! > What error message does it raise? Regards, John Ralls |
From: Jerome <rom...@ya...> - 2014-06-16 18:05:20
|
sed: impossible de lire : Aucun fichier ou dossier de ce type => sed: cannot read: No file or directory of this type $ find gramps/plugins/* -name *.gpr.py -exec sed -e s/gramps_target_version=4.1/gramps_target_version=4.2/ {} \; runs without error (it prints, no changes). It looks like related to: sed -i '' Regards, Jérôme Le lun. 16 juin 2014 at 19:23, John Ralls <jr...@ce...> a écrit : > > On 16 Jun 2014, at 10:03, Jerome <rom...@ya...> wrote: > >> Thanks! >> >> The first part works fine. >> >> eg, >> >> $ find gramps/plugins/* -name *.gpr.py >> >> but on the second part, sed cannot read these files under my config! >> >> > What error message does it raise? > > Regards, > John Ralls > > > |
From: Jerome <rom...@ya...> - 2014-06-16 18:16:16
|
Should I put a $pwd somewhere on the command line? Le lun. 16 juin 2014 at 20:03, Jerome <rom...@ya...> a écrit : > sed: impossible de lire : Aucun fichier ou dossier de ce type > => sed: cannot read: No file or directory of this type > > $ find gramps/plugins/* -name *.gpr.py -exec sed -e > s/gramps_target_version=4.1/gramps_target_version=4.2/ {} \; > > runs without error (it prints, no changes). > > It looks like related to: > sed -i '' > > > Regards, > Jérôme > > > Le lun. 16 juin 2014 at 19:23, John Ralls <jr...@ce...> a > écrit : >> >> On 16 Jun 2014, at 10:03, Jerome <rom...@ya...> wrote: >> >>> Thanks! >>> >>> The first part works fine. >>> >>> eg, >>> >>> $ find gramps/plugins/* -name *.gpr.py >>> >>> but on the second part, sed cannot read these files under my >>> config! >>> >>> >> What error message does it raise? >> >> Regards, >> John Ralls >> >> >> |
From: John R. <jr...@ce...> - 2014-06-16 19:26:08
|
On Jun 16, 2014, at 11:14 AM, Jerome <rom...@ya...> wrote: > Should I put a $pwd somewhere on the command line? > > Le lun. 16 juin 2014 at 20:03, Jerome <rom...@ya...> a écrit : >> sed: impossible de lire : Aucun fichier ou dossier de ce type >> => sed: cannot read: No file or directory of this type >> >> $ find gramps/plugins/* -name *.gpr.py -exec sed -e s/gramps_target_version=4.1/gramps_target_version=4.2/ {} \; >> >> runs without error (it prints, no changes). >> >> It looks like related to: >> sed -i '' Yeah, sorry, on Linux there should be no space, so `sed -i’’ …`. And the replacement string is gramps_target_version = ‘4.1’, so the working command is: find gramps/plugins -name *.gpr.py -exec sed -i'' -e "s/gramps_target_version = '4.1'/gramps_target_version = '4.2'/" {} \; That leaves gramps/plugins/view/geography.gpr.py, which defines MODULE_VERSION=“4.1”, but that’s just one line in one file, so it’s perhaps easier to hand-edit it. Regards, John Ralls |
From: Paul F. <pf....@gm...> - 2014-06-16 20:42:33
|
> And the replacement string is gramps_target_version = '4.1', Ah yes, but the observant recursive grepper will have noticed that some .gpr.py files have '4.1' and others have "4.1" (with the two different types of quotation marks). So maybe whoever does it might need to have a small shell script, and not attempt to do it in one line, even if it doubtless could technically be done in one? Just a thought. |
From: John R. <jr...@ce...> - 2014-06-17 03:34:13
|
On 16 Jun 2014, at 13:42, Paul Franklin <pf....@gm...> wrote: >> And the replacement string is gramps_target_version = '4.1', > > Ah yes, but the observant recursive grepper will have noticed > that some .gpr.py files have '4.1' and others have "4.1" (with the > two different types of quotation marks). > > So maybe whoever does it might need to have a small shell > script, and not attempt to do it in one line, even if it doubtless > could technically be done in one? > > Just a thought. [Oops, wrong from address.] Don't know regular expressions well, I guess: find gramps/plugins -name *.gpr.py -exec sed -i'' -e "s/gramps_target_version = ["']4.1["']/gramps_target_version = '4.2'/" {} \; Regards, John Ralls |
From: Paul F. <pf....@gm...> - 2014-06-17 07:04:13
|
On 6/16/14, John Ralls <jr...@ce...> wrote: > Don't know regular expressions well, I guess: > > find gramps/plugins -name *.gpr.py -exec sed -i'' -e > "s/gramps_target_version = ["']4.1["']/gramps_target_version = '4.2'/" {} > \; find gramps -name *.gpr.py -exec sed -i'' -e /gramps_target_version/s/4.1/4.2/ {} \; You like to write long commands, I guess. |
From: Jerome <rom...@ya...> - 2014-06-17 17:14:04
|
Ahh, both work fine. :) I am reassured ... we will be able to do this change, quickly! Thanks! Le mar. 17 juin 2014 at 9:04, Paul Franklin <pf....@gm...> a écrit : > On 6/16/14, John Ralls <jr...@ce...> wrote: >> Don't know regular expressions well, I guess: >> >> find gramps/plugins -name *.gpr.py -exec sed -i'' -e >> "s/gramps_target_version = ["']4.1["']/gramps_target_version = >> '4.2'/" {} >> \; >> > find gramps -name *.gpr.py -exec sed -i'' -e > /gramps_target_version/s/4.1/4.2/ {} \; > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk > Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Paul F. <pf....@gm...> - 2014-06-17 17:39:41
|
> I am reassured ... we will be able to do this change, quickly! Don't forget to change the geography.gpr.py that John found. Personally, if it were me, I would change it to be like every other gpr.py file, with an explicit "4.2" in every line, and get rid of that constant, so we don't have to remember to do a special-case change to that file on every major release. But you are the release manager. Maybe your memory is better than mine! 8-) |
From: John R. <jr...@ce...> - 2014-06-17 17:47:14
|
On Jun 17, 2014, at 10:39 AM, Paul Franklin <pf....@gm...> wrote: >> I am reassured ... we will be able to do this change, quickly! > > Don't forget to change the geography.gpr.py that John found. > > Personally, if it were me, I would change it to be like every > other gpr.py file, with an explicit "4.2" in every line, and get > rid of that constant, so we don't have to remember to do a > special-case change to that file on every major release. Better yet, change everything to get the version from const.py so we don’t have to this exercise at all. Regards, John Ralls |
From: Jerome <rom...@ya...> - 2014-06-17 18:37:46
|
I thought it breaks the logic of plugins check! It is the core set of plugins, but it also means that one will be able to run a core plugin generated for '4.2' into gramps '4.3', '4.4', '5.0', etc ... I suppose this check is more important for addons than for core set of plugins provided with gramps installation? Le mar. 17 juin 2014 at 19:47, John Ralls <jr...@ce...> a écrit : > Better yet, change everything to get the version from const.py so we > don’t have to this exercise at all. > > Regards, > John Ralls > > |
From: Paul F. <pf....@gm...> - 2014-06-17 19:18:43
|
> I thought it breaks the logic of plugins check! That's the impression I have too. But I wasn't around when the plugin system was started and so I don't claim to be able to accurately reproduce the rationale behind it. Or debate it from all points of view. However I do have the distinct impression that the concept of having to manually force such a version-number increase was integral to the whole philosophy, to magically somehow force developers into making sure that older things were upgraded, when necessary. But as I pointed out over a year ago, IMHO that is not done at all and instead a brute-force upgrade of the number is done instead, always -- just like we are talking about doing now. Including on the gramps-addons repo, where it is even more likely that older things will not have been updated. So as everybody knows I'd like to see the whole plugin system drastically changed, but as everybody also knows as a junior developer I have no chance at all to cause that to happen. |
From: Doug B. <dou...@gm...> - 2014-06-18 00:43:31
|
On Tue, Jun 17, 2014 at 3:18 PM, Paul Franklin <pf....@gm...> wrote: > > I thought it breaks the logic of plugins check! > > That's the impression I have too. > > But I wasn't around when the plugin system was started > and so I don't claim to be able to accurately reproduce the > rationale behind it. Or debate it from all points of view. > > However I do have the distinct impression that the concept > of having to manually force such a version-number increase > was integral to the whole philosophy, to magically somehow > force developers into making sure that older things were > upgraded, when necessary. > > But as I pointed out over a year ago, IMHO that is not done > at all and instead a brute-force upgrade of the number is done > instead, always -- just like we are talking about doing now. > > Including on the gramps-addons repo, where it is even more > likely that older things will not have been updated. > > So as everybody knows I'd like to see the whole plugin system > drastically changed, but as everybody also knows as a junior > developer I have no chance at all to cause that to happen. > The addon numbering was designed to only allow the right versions of plugins to work. For example: * if you just take some random plugin/addon and drop it in, it probably won't work. This was happening a lot in the old days as people were sharing their homemade plugins, and they didn't work. We can now tell why it doesn't work... oh, it was designed for 2.4. * addons can be made to only work to a point, or only after a point (for example, after 5.2.3) * more specific versions will override less specific versions Yes, the numbering must be bumped up on each major.minor version release. That can be as easy as as "sed -i ..." or might involve each addon being examined, and updated. I would say that we try to pick the best system, regardless if it comes from a "junior developer" (there is no such thing). If you have a better idea, please make a GEP, write some code, and put it out there as a pull request :) -Doug > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <ni...@gr...> - 2014-06-18 18:15:34
|
On 18/06/14 01:43, Doug Blank wrote: > If you have a better idea, please make a GEP, write some code, and put > it out there as a pull request :) > Why don't we just skip the target version check for core plugins? Core plugins will always be found below the PLUGINS_DIR directory. We don't need the plugin version for core plugins either. Nick. |
From: Doug B. <dou...@gm...> - 2014-06-19 00:18:07
|
On Wed, Jun 18, 2014 at 2:15 PM, Nick Hall <ni...@gr...> wrote: > On 18/06/14 01:43, Doug Blank wrote: > > If you have a better idea, please make a GEP, write some code, and put > > it out there as a pull request :) > > > > Why don't we just skip the target version check for core plugins? > > Core plugins will always be found below the PLUGINS_DIR directory. We > don't need the plugin version for core plugins either. > There have been times in the past that we released (via addons) a higher-versioned plugin that would be used rather than the core version. So, I think we still might want to have the numbering. But it could be provided through a standard means like Jerome suggested. -Doug > > Nick. > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <ni...@gr...> - 2014-06-19 11:47:39
|
On 19/06/14 01:17, Doug Blank wrote: > > Why don't we just skip the target version check for core plugins? > > Core plugins will always be found below the PLUGINS_DIR directory. We > don't need the plugin version for core plugins either. > > > There have been times in the past that we released (via addons) a > higher-versioned plugin that would be used rather than the core > version. So, I think we still might want to have the numbering. But it > could be provided through a standard means like Jerome suggested. I'm not suggesting that core plugins don't use the version number, just that they could use a default. Also checking the target version seems unnecessary for core plugins. Nick. |