gramps

There is 2/3 issues on references with the 'extract_messages' command.
Minor issue when we update the template for translations.

'plugins/lib/holidays.xml.in' is missing:

       os.system('''intltool-extract --type=gettext/xml src/plugins/lib/holidays.xml.in''')

        os.system('''xgettext -j --keyword=N_ --from-code=UTF-8'''
                  ''' -o "po/gramps.pot" '''
                  '''src/*/*.glade.h src/*/*/*.glade '''
                  ''' */*.in.h */*/*.in.h */*/*/*.in.h''')

and do not need to merge tips.xml with translations.

http://www.gramps-project.org/bugs/view.php?id=5621#c23384

I will make the change on next days.


-- 
Jérôme


--- En date de : Lun 12.3.12, jerome <romjerome@...> a écrit :

> De: jerome <romjerome@...>
> Objet: [Gramps-devel] setup.py
> À: gramps-devel@...
> Date: Lundi 12 mars 2012, 18h39
> Hi,
> 
> 
> I suppose I have finished what I planned with the
> experimental 'setup.py'.
> I tested 'babel' classes[1], but it looks like that there is
> nothing that we cannot make ourself. So, do not need an
> other dependency.
> 
> Unfortunately, I did not find a multiplatform tool for
> extracting and merging some specific entries (.glade, .xml,
> .keys, .desktop). 
> This means that extracting messages should be performed with
> installed intltool[2]. Note, it is only for generating a new
> template (gramps.pot) and building/installing Gramps does
> not need it.
> 
> I wanted to put this part out of 'setup.py', but I also
> re-used some available lists (files to install). Otherwise,
> we may also would like to have an up-to-date 'gramps.pot'
> with code for people who do not use SVN.
> 
> I also modified the common 'build, install' commands!
> Why ? Because of rights issues (user/admin) and some
> specific Gramps' things that distutils[3] does not use by
> default! It was also simplier to test without some of these
> classes... The uninstall class is also inherited from some
> others 'setup.py'. And these __init__.py everywhere is not
> very nice! Not certain that 'setuptools' is a good
> choice...
> 
> Anyway, once we know what should be done with some
> non-python files (glade, css, images, etc ...) and if it
> should generate multiple packages according to current
> ecosystem (webbapp, gen, gui, etc ...), then it seems that
> with minor changes we could have a working 'setup.py'.
> 
> I tried to add comments where something has to be fixed or
> where there is some possible specific behavior. I generated
> some .rpm packages for Gramps under OpenSuse in the past and
> I hope that everything is correct on this 'setup.py', but I
> also know that I tried to use what is currently working
> under my configuration and that cannot be used for
> production. 
> 
> PS: during investigations, I saw some custom strings:
> src/ExportAssistant.py:494:
> src/gramps.py:115
> src/Filters/SideBar/_PersonSidebarFilter.py:131
> src/Filters/SideBar/_PersonSidebarFilter.py:133
> src/cli/clidbman.py:78
> src/gen/db/upgrade.py:81
> src/gen/db/upgrade.py:82
> src/gen/db/upgrade.py:83
> src/gen/db/upgrade.py:84
> src/gen/db/upgrade.py:85
> src/gen/db/upgrade.py:86
> src/gen/plug/utils.py:271
> src/gui/makefilter.py:49
> src/gui/plug/_guioptions.py:844
> src/plugins/gramplet/EditExifMetadata.py:469
> src/plugins/gramplet/Notes.py:100
> src/plugins/lib/libgedcom.py:6414
> src/plugins/mapservices/eniroswedenmap.py:139
> src/plugins/mapservices/eniroswedenmap.py:140
> src/plugins/textreport/DetDescendantReport.py:576
> src/plugins/textreport/IndivComplete.py:208
> src/plugins/textreport/PlaceReport.py:225
> src/plugins/view/geofamily.py:299
> src/plugins/view/geofamily.py:306
> src/plugins/view/relview.py:1180
> src/plugins/view/relview.py:1182
> src/plugins/webreport/NarrativeWeb.py:1511
> src/plugins/webreport/NarrativeWeb.py:6938
> src/plugins/tool/mergecitations.glade:132
> 
> I assume they are not conform!
> We could also avoid to translate some strings used fr
> debbuging/log or some DB things. I will try to remove some
> translation marks on some of these files.
> 
> 
> [1] http://babel.edgewall.org/wiki/Documentation/setup.html
> [2] http://freedesktop.org/wiki/Software/intltool
> [3] http://docs.python.org/library/distutils.html#module-distutils
> 
> 
> regards,
> 
> -- 
> Jérôme
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft
> developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
> CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you
> subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

Good work.

In the end, moving to setup.py would be done so that gramps is installed in
default_location_python_lib/gramps/...

and other programs can do
from gramps.gen import ....

So that means we must change the current src directory into the name
gramps. If you want to do that in trunk, that would be great :-)
Many text changes to achieve that.

Then setup.py only installs this gramps directory to the library, and we
need extra code to create a gramps binary file /usr/bin, and a script to
extract the strings for internationalization. So the work you do here.

Note that for python 3 import rules become much stricter than in 2.2, so we
will need to fix some import statements for that too.

As to the python 3/gobject port, more people are hitting the bug in the
pygobject code, and there have been attempts to fix it, but pygobject
developers did not succeed yet. If that is not fixed, we are stuck on pygtk
and python 2.7.

Benny

2012/3/12 jerome <romjerome@...>

> There is 2/3 issues on references with the 'extract_messages' command.
> Minor issue when we update the template for translations.
>
> 'plugins/lib/holidays.xml.in' is missing:
>
>       os.system('''intltool-extract --type=gettext/xml src/plugins/lib/
> holidays.xml.in''')
>
>        os.system('''xgettext -j --keyword=N_ --from-code=UTF-8'''
>                  ''' -o "po/gramps.pot" '''
>                  '''src/*/*.glade.h src/*/*/*.glade '''
>                  ''' */*.in.h */*/*.in.h */*/*/*.in.h''')
>
> and do not need to merge tips.xml with translations.
>
> http://www.gramps-project.org/bugs/view.php?id=5621#c23384
>
> I will make the change on next days.
>
>
> --
> Jérôme
>
>
> --- En date de : Lun 12.3.12, jerome <romjerome@...> a écrit :
>
> > De: jerome <romjerome@...>
> > Objet: [Gramps-devel] setup.py
> > À: gramps-devel@...
> > Date: Lundi 12 mars 2012, 18h39
> > Hi,
> >
> >
> > I suppose I have finished what I planned with the
> > experimental 'setup.py'.
> > I tested 'babel' classes[1], but it looks like that there is
> > nothing that we cannot make ourself. So, do not need an
> > other dependency.
> >
> > Unfortunately, I did not find a multiplatform tool for
> > extracting and merging some specific entries (.glade, .xml,
> > .keys, .desktop).
> > This means that extracting messages should be performed with
> > installed intltool[2]. Note, it is only for generating a new
> > template (gramps.pot) and building/installing Gramps does
> > not need it.
> >
> > I wanted to put this part out of 'setup.py', but I also
> > re-used some available lists (files to install). Otherwise,
> > we may also would like to have an up-to-date 'gramps.pot'
> > with code for people who do not use SVN.
> >
> > I also modified the common 'build, install' commands!
> > Why ? Because of rights issues (user/admin) and some
> > specific Gramps' things that distutils[3] does not use by
> > default! It was also simplier to test without some of these
> > classes... The uninstall class is also inherited from some
> > others 'setup.py'. And these __init__.py everywhere is not
> > very nice! Not certain that 'setuptools' is a good
> > choice...
> >
> > Anyway, once we know what should be done with some
> > non-python files (glade, css, images, etc ...) and if it
> > should generate multiple packages according to current
> > ecosystem (webbapp, gen, gui, etc ...), then it seems that
> > with minor changes we could have a working 'setup.py'.
> >
> > I tried to add comments where something has to be fixed or
> > where there is some possible specific behavior. I generated
> > some .rpm packages for Gramps under OpenSuse in the past and
> > I hope that everything is correct on this 'setup.py', but I
> > also know that I tried to use what is currently working
> > under my configuration and that cannot be used for
> > production.
> >
> > PS: during investigations, I saw some custom strings:
> > src/ExportAssistant.py:494:
> > src/gramps.py:115
> > src/Filters/SideBar/_PersonSidebarFilter.py:131
> > src/Filters/SideBar/_PersonSidebarFilter.py:133
> > src/cli/clidbman.py:78
> > src/gen/db/upgrade.py:81
> > src/gen/db/upgrade.py:82
> > src/gen/db/upgrade.py:83
> > src/gen/db/upgrade.py:84
> > src/gen/db/upgrade.py:85
> > src/gen/db/upgrade.py:86
> > src/gen/plug/utils.py:271
> > src/gui/makefilter.py:49
> > src/gui/plug/_guioptions.py:844
> > src/plugins/gramplet/EditExifMetadata.py:469
> > src/plugins/gramplet/Notes.py:100
> > src/plugins/lib/libgedcom.py:6414
> > src/plugins/mapservices/eniroswedenmap.py:139
> > src/plugins/mapservices/eniroswedenmap.py:140
> > src/plugins/textreport/DetDescendantReport.py:576
> > src/plugins/textreport/IndivComplete.py:208
> > src/plugins/textreport/PlaceReport.py:225
> > src/plugins/view/geofamily.py:299
> > src/plugins/view/geofamily.py:306
> > src/plugins/view/relview.py:1180
> > src/plugins/view/relview.py:1182
> > src/plugins/webreport/NarrativeWeb.py:1511
> > src/plugins/webreport/NarrativeWeb.py:6938
> > src/plugins/tool/mergecitations.glade:132
> >
> > I assume they are not conform!
> > We could also avoid to translate some strings used fr
> > debbuging/log or some DB things. I will try to remove some
> > translation marks on some of these files.
> >
> >
> > [1] http://babel.edgewall.org/wiki/Documentation/setup.html
> > [2] http://freedesktop.org/wiki/Software/intltool
> > [3] http://docs.python.org/library/distutils.html#module-distutils
> >
> >
> > regards,
> >
> > --
> > Jérôme
> >
> >
> ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft
> > developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
> > CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you
> > subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > _______________________________________________
> > Gramps-devel mailing list
> > Gramps-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

I haven't followed what setup.py is doing, and I don't understand it, but...


Benny Malengier wrote
> 
> Good work.
> 
> In the end, moving to setup.py would be done so that gramps is installed
> in
> default_location_python_lib/gramps/...
> 
> and other programs can do
> from gramps.gen import ....
> 
> So that means we must change the current src directory into the name
> gramps. If you want to do that in trunk, that would be great :-)
> Many text changes to achieve that.
> 
> Then setup.py only installs this gramps directory to the library, and we
> need extra code to create a gramps binary file /usr/bin, and a script to
> extract the strings for internationalization. So the work you do here.
> 
> Note that for python 3 import rules become much stricter than in 2.2, so
> we
> will need to fix some import statements for that too.
> 
> As to the python 3/gobject port, more people are hitting the bug in the
> pygobject code, and there have been attempts to fix it, but pygobject
> developers did not succeed yet. If that is not fixed, we are stuck on
> pygtk
> and python 2.7.
> 


Would this mean it was no longer possible to run Gramps direct from the
local svn repository? If so that would be terrible!

--
View this message in context: http://gramps.1791082.n4.nabble.com/setup-py-tp4466768p4469226.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

2012/3/13 Tim Lyons <guy.linton@...>

> I haven't followed what setup.py is doing, and I don't understand it,
> but...
>
>
> Benny Malengier wrote
> >
> > Good work.
> >
> > In the end, moving to setup.py would be done so that gramps is installed
> > in
> > default_location_python_lib/gramps/...
> >
> > and other programs can do
> > from gramps.gen import ....
> >
> > So that means we must change the current src directory into the name
> > gramps. If you want to do that in trunk, that would be great :-)
> > Many text changes to achieve that.
> >
> > Then setup.py only installs this gramps directory to the library, and we
> > need extra code to create a gramps binary file /usr/bin, and a script to
> > extract the strings for internationalization. So the work you do here.
> >
> > Note that for python 3 import rules become much stricter than in 2.2, so
> > we
> > will need to fix some import statements for that too.
> >
> > As to the python 3/gobject port, more people are hitting the bug in the
> > pygobject code, and there have been attempts to fix it, but pygobject
> > developers did not succeed yet. If that is not fixed, we are stuck on
> > pygtk
> > and python 2.7.
> >
>
>
> Would this mean it was no longer possible to run Gramps direct from the
> local svn repository? If so that would be terrible!
>

No, that is not related. Just like you must not do

from src.gen import ...

now,  with a gramps top directory you would not need to do

from gramps.gen import ...

You would however need to include gramps for external import. You then use
something like:
PYTHONPATH=/path_to_svn/gramps33 mytest.py
where mytest has a statement  from gramps.gen import ...
If gramps is installed, then PYTHONPATH is not needed.

However, there will be no const.py then in linux like you have now after
running make, so the situation would be like it is in windows already! You
or do
1/ rename const.py.in to const.py
2/ or you do the official: python setup.py build, and then run gramps from
the build directory instead of from the sourcefile directory. Schooled
programmers should understand that that is by far the better approach than
what we are used to do now (where build and source are combined in a single
directory).

Should anybody ever want to mix in some cython with our current code to
improve performance, using a build directory is anyway the way to proceed.

Benny

>
> --
> View this message in context:
> http://gramps.1791082.n4.nabble.com/setup-py-tp4466768p4469226.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

> So that means we must change the current src directory into the name 
> gramps. If you want to do that in trunk, that would be great :-)
> Many text changes to achieve that.

Should we create a GEPS branch?
http://gramps.svn.sourceforge.net/viewvc/gramps/branches/geps/

It is close to GEPS12:
http://www.gramps-project.org/wiki/index.php?title=GEPS_012:_Ecosystem_definition


Jérôme

Benny Malengier a écrit :
> Good work.
> 
> In the end, moving to setup.py would be done so that gramps is installed in
> default_location_python_lib/gramps/...
> 
> and other programs can do
> from gramps.gen import ....
> 
> So that means we must change the current src directory into the name 
> gramps. If you want to do that in trunk, that would be great :-)
> Many text changes to achieve that.
> 
> Then setup.py only installs this gramps directory to the library, and we 
> need extra code to create a gramps binary file /usr/bin, and a script to 
> extract the strings for internationalization. So the work you do here.
> 
> Note that for python 3 import rules become much stricter than in 2.2, so 
> we will need to fix some import statements for that too.
> 
> As to the python 3/gobject port, more people are hitting the bug in the 
> pygobject code, and there have been attempts to fix it, but pygobject 
> developers did not succeed yet. If that is not fixed, we are stuck on 
> pygtk and python 2.7.
> 
> Benny
>     ------------------------------------------------------------------------------
>     Try before you buy = See our experts in action!
>     The most comprehensive online learning library for Microsoft developers
>     is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>     Metro Style Apps, more. Free future releases when you subscribe now!
>     http://p.sf.net/sfu/learndevnow-dev2
>     _______________________________________________
>     Gramps-devel mailing list
>     Gramps-devel@...
>     <mailto:Gramps-devel@...>
>     https://lists.sourceforge.net/lists/listinfo/gramps-devel
> 
>

> Would this mean it was no longer possible to run Gramps direct from the
> local svn repository? If so that would be terrible!

You do not need to run from the local svn repository... but you can run 
a copy without SVN files and references! eg, you do not want to run from 
the local svn repository, you have some local modifications and you want 
to try a 'clean' revision, or you do not have your SVN account and can 
access to the net.

1. download:
http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/?view=tar
and extract this archive somewhere on your disk
2. rename 'src/const.py.in' to 'src/const.py'
3. $ python src/gramps.py

It is not an installation but you can run Gramps direct from your disk. :)


Jérôme


Tim Lyons a écrit :
> I haven't followed what setup.py is doing, and I don't understand it, but...
> 
> 
> Benny Malengier wrote
>> Good work.
>>
>> In the end, moving to setup.py would be done so that gramps is installed
>> in
>> default_location_python_lib/gramps/...
>>
>> and other programs can do
>> from gramps.gen import ....
>>
>> So that means we must change the current src directory into the name
>> gramps. If you want to do that in trunk, that would be great :-)
>> Many text changes to achieve that.
>>
>> Then setup.py only installs this gramps directory to the library, and we
>> need extra code to create a gramps binary file /usr/bin, and a script to
>> extract the strings for internationalization. So the work you do here.
>>
>> Note that for python 3 import rules become much stricter than in 2.2, so
>> we
>> will need to fix some import statements for that too.
>>
>> As to the python 3/gobject port, more people are hitting the bug in the
>> pygobject code, and there have been attempts to fix it, but pygobject
>> developers did not succeed yet. If that is not fixed, we are stuck on
>> pygtk
>> and python 2.7.
>>
> 
> 
> Would this mean it was no longer possible to run Gramps direct from the
> local svn repository? If so that would be terrible!
> 
> --
> View this message in context: http://gramps.1791082.n4.nabble.com/setup-py-tp4466768p4469226.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

2012/3/14 Jérôme <romjerome@...>

> So that means we must change the current src directory into the name
>> gramps. If you want to do that in trunk, that would be great :-)
>> Many text changes to achieve that.
>>
>
> Should we create a GEPS branch?
> http://gramps.svn.sourceforge.**net/viewvc/gramps/branches/**geps/<http://gramps.svn.sourceforge.net/viewvc/gramps/branches/geps/>
>
>
If you think you feel up to the task of finishing this for gramps 3.5, yes,
otherwise, try things out locally and add a GEPS in the wiki for it where
you document how it should be done in the end, and a ticket in bug tracker
where files are attached.

Benny

It is close to GEPS12:
> http://www.gramps-project.org/**wiki/index.php?title=GEPS_012:**
> _Ecosystem_definition<http://www.gramps-project.org/wiki/index.php?title=GEPS_012:_Ecosystem_definition>
>
>
> Jérôme
>
> Benny Malengier a écrit :
>
>> Good work.
>>
>> In the end, moving to setup.py would be done so that gramps is installed
>> in
>> default_location_python_lib/**gramps/...
>>
>> and other programs can do
>> from gramps.gen import ....
>>
>> So that means we must change the current src directory into the name
>> gramps. If you want to do that in trunk, that would be great :-)
>> Many text changes to achieve that.
>>
>> Then setup.py only installs this gramps directory to the library, and we
>> need extra code to create a gramps binary file /usr/bin, and a script to
>> extract the strings for internationalization. So the work you do here.
>>
>> Note that for python 3 import rules become much stricter than in 2.2, so
>> we will need to fix some import statements for that too.
>>
>> As to the python 3/gobject port, more people are hitting the bug in the
>> pygobject code, and there have been attempts to fix it, but pygobject
>> developers did not succeed yet. If that is not fixed, we are stuck on pygtk
>> and python 2.7.
>>
>> Benny
>>    ------------------------------**------------------------------**
>> ------------------
>>    Try before you buy = See our experts in action!
>>    The most comprehensive online learning library for Microsoft developers
>>    is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
>> MVC3,
>>    Metro Style Apps, more. Free future releases when you subscribe now!
>>    http://p.sf.net/sfu/**learndevnow-dev2<http://p.sf.net/sfu/learndevnow-dev2>
>>    ______________________________**_________________
>>    Gramps-devel mailing list
>>    Gramps-devel@...>
>>    <mailto:Gramps-devel@...>
>> >
>>    https://lists.sourceforge.net/**lists/listinfo/gramps-devel<https://lists.sourceforge.net/lists/listinfo/gramps-devel>
>>
>>
>>
>

They will find a solution for get_value and Gtk.TreeModel (pygobject)[1].

Next major release could move to python3, will be named Gramps 4.0 and 
we do not need Makefile environment any more, by using 'setup.py'. ;)

In this case, this can be finished with few changes: svn move command, 
fix references/links on 'setup.py'!

As said, the problem might be the packaging (after the release).

It will be simplier for CPython, Python folks, but Aunt Martha can wait 
some time since packagers have a good common 'cross 
platform/environment/os/FHS[3]/versions' solution... :(


[1] https://bugzilla.gnome.org/show_bug.cgi?id=653151
[2] http://hg.python.org/distutils2/file/9095d3ce29b5/docs/design/wiki.rst
[3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard


Jérôme

Benny Malengier a écrit :
> 
> 
> 2012/3/14 Jérôme <romjerome@... <mailto:romjerome@...>>
> 
>         So that means we must change the current src directory into the
>         name gramps. If you want to do that in trunk, that would be
>         great :-)
>         Many text changes to achieve that.
> 
> 
>     Should we create a GEPS branch?
>     http://gramps.svn.sourceforge. net/viewvc/gramps/branches/ geps/
>     <http://gramps.svn.sourceforge.net/viewvc/gramps/branches/geps/>
> 
> 
> If you think you feel up to the task of finishing this for gramps 3.5, 
> yes, otherwise, try things out locally and add a GEPS in the wiki for it 
> where you document how it should be done in the end, and a ticket in bug 
> tracker where files are attached.
> 
> Benny
> 
>     It is close to GEPS12:
>     http://www.gramps-project.org/ wiki/index.php?title=GEPS_012:
>     _Ecosystem_definition
>     <http://www.gramps-project.org/wiki/index.php?title=GEPS_012:_Ecosystem_definition>
> 
> 
>     Jérôme
> 
>     Benny Malengier a écrit :
> 
>         Good work.
> 
>         In the end, moving to setup.py would be done so that gramps is
>         installed in
>         default_location_python_lib/ gramps/...
> 
>         and other programs can do
>         from gramps.gen import ....
> 
>         So that means we must change the current src directory into the
>         name gramps. If you want to do that in trunk, that would be
>         great :-)
>         Many text changes to achieve that.
> 
>         Then setup.py only installs this gramps directory to the
>         library, and we need extra code to create a gramps binary file
>         /usr/bin, and a script to extract the strings for
>         internationalization. So the work you do here.
> 
>         Note that for python 3 import rules become much stricter than in
>         2.2, so we will need to fix some import statements for that too.
> 
>         As to the python 3/gobject port, more people are hitting the bug
>         in the pygobject code, and there have been attempts to fix it,
>         but pygobject developers did not succeed yet. If that is not
>         fixed, we are stuck on pygtk and python 2.7.
> 
>         Benny
>            ------------------------------ ------------------------------
>         ------------------
>            Try before you buy = See our experts in action!
>            The most comprehensive online learning library for Microsoft
>         developers
>            is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
>         CSS3, MVC3,
>            Metro Style Apps, more. Free future releases when you
>         subscribe now!
>            http://p.sf.net/sfu/ learndevnow-dev2
>         <http://p.sf.net/sfu/learndevnow-dev2>
>            ______________________________ _________________
>            Gramps-devel mailing list
>            Gramps-devel@.... sourceforge.net
>         <mailto:Gramps-devel@...>
>            <mailto:Gramps-devel@.... sourceforge.net
>         <mailto:Gramps-devel@...>>
>            https://lists.sourceforge.net/ lists/listinfo/gramps-devel
>         <https://lists.sourceforge.net/lists/listinfo/gramps-devel>
> 
> 
> 
>

On 14 Mar 2012, at 09:23, Jérôme wrote:

>> Would this mean it was no longer possible to run Gramps direct from  
>> the
>> local svn repository? If so that would be terrible!
>
> You do not need to run from the local svn repository... but you can  
> run a copy without SVN files and references! eg, you do not want to  
> run from the local svn repository, you have some local modifications  
> and you want to try a 'clean' revision, or you do not have your SVN  
> account and can access to the net.

But I WANT to run from the local SVN repository. That is an ESSENTIAL  
part of my work-flow for making bug fixes and changes to Gramps!

Copying to another local directory would really slow down making  
changes.

jerome wrote
> 
> They will find a solution for get_value and Gtk.TreeModel (pygobject)[1].
> 
> Next major release could move to python3, will be named Gramps 4.0 and 
> we do not need Makefile environment any more, by using 'setup.py'. ;)
> 
> In this case, this can be finished with few changes: svn move command, 
> fix references/links on 'setup.py'!
> 
> As said, the problem might be the packaging (after the release).
> 
> It will be simplier for CPython, Python folks, but Aunt Martha can wait 
> some time since packagers have a good common 'cross 
> platform/environment/os/FHS[3]/versions' solution... :(
> 

As is also mentioned in the other thread (URGENT ATTENTION: separate gramps
directory structure) in view of the impact on the various ports and
installations, I think it would be much safer to progress such a radical
change in a GEPS, and make sure it can be implemented in various platforms
before merging into trunk.


--
View this message in context: http://gramps.1791082.n4.nabble.com/setup-py-tp4466768p4474628.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Hi,

currently, I prefer make.
How can we do "make clean" with setup.py ?
When we often do svn up, if some files are renamed or suppressed, make clean is used to remove all *.pyc", ...
If we do "make distclean", we restart as if the gramps tree was new ( remove all config files, ... )


Le 12/03/2012 18:39, jerome a écrit :
> Hi,
>
>
> I suppose I have finished what I planned with the experimental 'setup.py'.
> I tested 'babel' classes[1], but it looks like that there is nothing that we cannot make ourself. So, do not need an other dependency.
>
> Unfortunately, I did not find a multiplatform tool for extracting and merging some specific entries (.glade, .xml, .keys, .desktop).
> This means that extracting messages should be performed with installed intltool[2]. Note, it is only for generating a new template (gramps.pot) and building/installing Gramps does not need it.
>
> I wanted to put this part out of 'setup.py', but I also re-used some available lists (files to install). Otherwise, we may also would like to have an up-to-date 'gramps.pot' with code for people who do not use SVN.
>
> I also modified the common 'build, install' commands!
> Why ? Because of rights issues (user/admin) and some specific Gramps' things that distutils[3] does not use by default! It was also simplier to test without some of these classes... The uninstall class is also inherited from some others 'setup.py'. And these __init__.py everywhere is not very nice! Not certain that 'setuptools' is a good choice...
>
> Anyway, once we know what should be done with some non-python files (glade, css, images, etc ...) and if it should generate multiple packages according to current ecosystem (webbapp, gen, gui, etc ...), then it seems that with minor changes we could have a working 'setup.py'.
>
> I tried to add comments where something has to be fixed or where there is some possible specific behavior. I generated some .rpm packages for Gramps under OpenSuse in the past and I hope that everything is correct on this 'setup.py', but I also know that I tried to use what is currently working under my configuration and that cannot be used for production.
>
> PS: during investigations, I saw some custom strings:
> src/ExportAssistant.py:494:
> src/gramps.py:115
> src/Filters/SideBar/_PersonSidebarFilter.py:131
> src/Filters/SideBar/_PersonSidebarFilter.py:133
> src/cli/clidbman.py:78
> src/gen/db/upgrade.py:81
> src/gen/db/upgrade.py:82
> src/gen/db/upgrade.py:83
> src/gen/db/upgrade.py:84
> src/gen/db/upgrade.py:85
> src/gen/db/upgrade.py:86
> src/gen/plug/utils.py:271
> src/gui/makefilter.py:49
> src/gui/plug/_guioptions.py:844
> src/plugins/gramplet/EditExifMetadata.py:469
> src/plugins/gramplet/Notes.py:100
> src/plugins/lib/libgedcom.py:6414
> src/plugins/mapservices/eniroswedenmap.py:139
> src/plugins/mapservices/eniroswedenmap.py:140
> src/plugins/textreport/DetDescendantReport.py:576
> src/plugins/textreport/IndivComplete.py:208
> src/plugins/textreport/PlaceReport.py:225
> src/plugins/view/geofamily.py:299
> src/plugins/view/geofamily.py:306
> src/plugins/view/relview.py:1180
> src/plugins/view/relview.py:1182
> src/plugins/webreport/NarrativeWeb.py:1511
> src/plugins/webreport/NarrativeWeb.py:6938
> src/plugins/tool/mergecitations.glade:132
>
> I assume they are not conform!
> We could also avoid to translate some strings used fr debbuging/log or some DB things. I will try to remove some translation marks on some of these files.
>
>
> [1] http://babel.edgewall.org/wiki/Documentation/setup.html
> [2] http://freedesktop.org/wiki/Software/intltool
> [3] http://docs.python.org/library/distutils.html#module-distutils
>
>
> regards,
>

> How can we do "make clean" with setup.py ?

'python setup.py clean' ...

http://docs.python.org/distutils/apiref.html#module-distutils.command.clean
http://pydoc.org/2.5.1/distutils.command.clean.html#clean

There is a created 'build' directory.
Nothing should be added on /src like with make! ;)


Jérôme

Serge Noiraud a écrit :
> Hi,
> 
> currently, I prefer make.
> How can we do "make clean" with setup.py ?
> When we often do svn up, if some files are renamed or suppressed, make 
> clean is used to remove all *.pyc", ...
> If we do "make distclean", we restart as if the gramps tree was new ( 
> remove all config files, ... )
> 
> 
> Le 12/03/2012 18:39, jerome a écrit :
>> Hi,
>>
>>
>> I suppose I have finished what I planned with the experimental 
>> 'setup.py'.
>> I tested 'babel' classes[1], but it looks like that there is nothing 
>> that we cannot make ourself. So, do not need an other dependency.
>>
>> Unfortunately, I did not find a multiplatform tool for extracting and 
>> merging some specific entries (.glade, .xml, .keys, .desktop).
>> This means that extracting messages should be performed with installed 
>> intltool[2]. Note, it is only for generating a new template 
>> (gramps.pot) and building/installing Gramps does not need it.
>>
>> I wanted to put this part out of 'setup.py', but I also re-used some 
>> available lists (files to install). Otherwise, we may also would like 
>> to have an up-to-date 'gramps.pot' with code for people who do not use 
>> SVN.
>>
>> I also modified the common 'build, install' commands!
>> Why ? Because of rights issues (user/admin) and some specific Gramps' 
>> things that distutils[3] does not use by default! It was also simplier 
>> to test without some of these classes... The uninstall class is also 
>> inherited from some others 'setup.py'. And these __init__.py 
>> everywhere is not very nice! Not certain that 'setuptools' is a good 
>> choice...
>>
>> Anyway, once we know what should be done with some non-python files 
>> (glade, css, images, etc ...) and if it should generate multiple 
>> packages according to current ecosystem (webbapp, gen, gui, etc ...), 
>> then it seems that with minor changes we could have a working 'setup.py'.
>>
>> I tried to add comments where something has to be fixed or where there 
>> is some possible specific behavior. I generated some .rpm packages for 
>> Gramps under OpenSuse in the past and I hope that everything is 
>> correct on this 'setup.py', but I also know that I tried to use what 
>> is currently working under my configuration and that cannot be used 
>> for production.
>>
>> PS: during investigations, I saw some custom strings:
>> src/ExportAssistant.py:494:
>> src/gramps.py:115
>> src/Filters/SideBar/_PersonSidebarFilter.py:131
>> src/Filters/SideBar/_PersonSidebarFilter.py:133
>> src/cli/clidbman.py:78
>> src/gen/db/upgrade.py:81
>> src/gen/db/upgrade.py:82
>> src/gen/db/upgrade.py:83
>> src/gen/db/upgrade.py:84
>> src/gen/db/upgrade.py:85
>> src/gen/db/upgrade.py:86
>> src/gen/plug/utils.py:271
>> src/gui/makefilter.py:49
>> src/gui/plug/_guioptions.py:844
>> src/plugins/gramplet/EditExifMetadata.py:469
>> src/plugins/gramplet/Notes.py:100
>> src/plugins/lib/libgedcom.py:6414
>> src/plugins/mapservices/eniroswedenmap.py:139
>> src/plugins/mapservices/eniroswedenmap.py:140
>> src/plugins/textreport/DetDescendantReport.py:576
>> src/plugins/textreport/IndivComplete.py:208
>> src/plugins/textreport/PlaceReport.py:225
>> src/plugins/view/geofamily.py:299
>> src/plugins/view/geofamily.py:306
>> src/plugins/view/relview.py:1180
>> src/plugins/view/relview.py:1182
>> src/plugins/webreport/NarrativeWeb.py:1511
>> src/plugins/webreport/NarrativeWeb.py:6938
>> src/plugins/tool/mergecitations.glade:132
>>
>> I assume they are not conform!
>> We could also avoid to translate some strings used fr debbuging/log or 
>> some DB things. I will try to remove some translation marks on some of 
>> these files.
>>
>>
>> [1] http://babel.edgewall.org/wiki/Documentation/setup.html
>> [2] http://freedesktop.org/wiki/Software/intltool
>> [3] http://docs.python.org/library/distutils.html#module-distutils
>>
>>
>> regards,
>>
> 
>

Things are different. If you run python in your source directory, then you
have problems like this. Running from source works for gramps because
nothing must be compiled, but is not a recommended workflow for any
programming language.
With setup.py, you are supposed to run the application from the build
directory, not the source, then removing the build dir removes all again
(no mix of source, and code that is run). This is better because if you for
example remove a directory from svn, and it remains on your local dir, from
src/.. you can still run code that imports from that directory. After
install, or build, the code will fail as it should. Doing make clean in the
source dir does not fix that, using a separate build dir does.

Benny
2012/3/16 Serge Noiraud <Serge.Noiraud@...>

> Hi,
>
> currently, I prefer make.
> How can we do "make clean" with setup.py ?
> When we often do svn up, if some files are renamed or suppressed, make
> clean is used to remove all *.pyc", ...
> If we do "make distclean", we restart as if the gramps tree was new (
> remove all config files, ... )
>
>
> Le 12/03/2012 18:39, jerome a écrit :
> > Hi,
> >
> >
> > I suppose I have finished what I planned with the experimental
> 'setup.py'.
> > I tested 'babel' classes[1], but it looks like that there is nothing
> that we cannot make ourself. So, do not need an other dependency.
> >
> > Unfortunately, I did not find a multiplatform tool for extracting and
> merging some specific entries (.glade, .xml, .keys, .desktop).
> > This means that extracting messages should be performed with installed
> intltool[2]. Note, it is only for generating a new template (gramps.pot)
> and building/installing Gramps does not need it.
> >
> > I wanted to put this part out of 'setup.py', but I also re-used some
> available lists (files to install). Otherwise, we may also would like to
> have an up-to-date 'gramps.pot' with code for people who do not use SVN.
> >
> > I also modified the common 'build, install' commands!
> > Why ? Because of rights issues (user/admin) and some specific Gramps'
> things that distutils[3] does not use by default! It was also simplier to
> test without some of these classes... The uninstall class is also inherited
> from some others 'setup.py'. And these __init__.py everywhere is not very
> nice! Not certain that 'setuptools' is a good choice...
> >
> > Anyway, once we know what should be done with some non-python files
> (glade, css, images, etc ...) and if it should generate multiple packages
> according to current ecosystem (webbapp, gen, gui, etc ...), then it seems
> that with minor changes we could have a working 'setup.py'.
> >
> > I tried to add comments where something has to be fixed or where there
> is some possible specific behavior. I generated some .rpm packages for
> Gramps under OpenSuse in the past and I hope that everything is correct on
> this 'setup.py', but I also know that I tried to use what is currently
> working under my configuration and that cannot be used for production.
> >
> > PS: during investigations, I saw some custom strings:
> > src/ExportAssistant.py:494:
> > src/gramps.py:115
> > src/Filters/SideBar/_PersonSidebarFilter.py:131
> > src/Filters/SideBar/_PersonSidebarFilter.py:133
> > src/cli/clidbman.py:78
> > src/gen/db/upgrade.py:81
> > src/gen/db/upgrade.py:82
> > src/gen/db/upgrade.py:83
> > src/gen/db/upgrade.py:84
> > src/gen/db/upgrade.py:85
> > src/gen/db/upgrade.py:86
> > src/gen/plug/utils.py:271
> > src/gui/makefilter.py:49
> > src/gui/plug/_guioptions.py:844
> > src/plugins/gramplet/EditExifMetadata.py:469
> > src/plugins/gramplet/Notes.py:100
> > src/plugins/lib/libgedcom.py:6414
> > src/plugins/mapservices/eniroswedenmap.py:139
> > src/plugins/mapservices/eniroswedenmap.py:140
> > src/plugins/textreport/DetDescendantReport.py:576
> > src/plugins/textreport/IndivComplete.py:208
> > src/plugins/textreport/PlaceReport.py:225
> > src/plugins/view/geofamily.py:299
> > src/plugins/view/geofamily.py:306
> > src/plugins/view/relview.py:1180
> > src/plugins/view/relview.py:1182
> > src/plugins/webreport/NarrativeWeb.py:1511
> > src/plugins/webreport/NarrativeWeb.py:6938
> > src/plugins/tool/mergecitations.glade:132
> >
> > I assume they are not conform!
> > We could also avoid to translate some strings used fr debbuging/log or
> some DB things. I will try to remove some translation marks on some of
> these files.
> >
> >
> > [1] http://babel.edgewall.org/wiki/Documentation/setup.html
> > [2] http://freedesktop.org/wiki/Software/intltool
> > [3] http://docs.python.org/library/distutils.html#module-distutils
> >
> >
> > regards,
> >
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>