From: Benny M. <ben...@gm...> - 2012-09-20 15:25:21
|
Nick, With Rob gone, how to proceed with http://www.gramps-project.org/wiki/index.php?title=GEPS_026:_Replace_%27make%27_for_Gramps_build Looking at that page, I don't see definite answers, more like a list of possible problems. You were involved with Rob in this if I remember correctly. Is distutils2 the way to go? If so, I would try to start that. I assume deleting all makefiles, and creating a setup.py is all that is needed. Then deciding if we need one or two packages (gramps/gen and rest). Benny |
From: Nick H. <nic...@ho...> - 2012-09-20 17:59:59
|
Benny, I was helping Rob. He was working on distutils2 which we should be able to get working for Linux quite easily. There are 3 python options: 1. distutils 2. setuptools 3. packaging (distutils2) The most modern is packaging which should be included in the next python release, but is available for earlier versions. It should include some of the useful features of setuptools. These tools provide 3 main functions: 1. Source distribution. Files for distribution can be specified in a manifest file, in a configuration file or by using a manifest builder. I wrote a manifest builder for distutils2 to include all files under subversion control. The problem with this is that different versions of subversion use different file formats. If we want to use a manifest builder, then we will need to run a subversion command rather than looking at the file system. At the moment I suggest using a manifest file. 2. Build. We don't actually build anything, but do run some translation utility scripts in this phase. In distutils2, hooks are provided to run custom scripts. In distutils and setuptools, custom scripts can be run by sub-classing commands. 3. Installation. Installation involves copying files to the appropriate locations. It is easy to specify where to install packages and package data. We did not fully investigate how to handle resources. In disutils2, they introduced a concept of resources. The idea was that you could specify a target such as {doc}. This would be substituted for the location of documentation, which is OS dependent. We may need to investigate how to define custom resource locations. For more complex software, such as Gramps, distutils2 could do with some more work. It is getting there, but not quickly. I'll get working what we have so far for you. Nick. On 20/09/12 16:25, Benny Malengier wrote: > Nick, > > With Rob gone, how to proceed with > http://www.gramps-project.org/wiki/index.php?title=GEPS_026:_Replace_%27make%27_for_Gramps_build > Looking at that page, I don't see definite answers, more like a list > of possible problems. > You were involved with Rob in this if I remember correctly. Is > distutils2 the way to go? > If so, I would try to start that. I assume deleting all makefiles, and > creating a setup.py is all that is needed. Then deciding if we need > one or two packages (gramps/gen and rest). > > Benny |
From: Benny M. <ben...@gm...> - 2012-09-20 18:20:23
|
2012/9/20 Nick Hall <nic...@ho...> > Benny, > > I was helping Rob. He was working on distutils2 which we should be able > to get working for Linux quite easily. > > There are 3 python options: > > 1. distutils > 2. setuptools > 3. packaging (distutils2) > > The most modern is packaging which should be included in the next python > release, but is available for earlier versions. It should include some of > the useful features of setuptools. > > These tools provide 3 main functions: > > 1. Source distribution. > > Files for distribution can be specified in a manifest file, in a > configuration file or by using a manifest builder. I wrote a manifest > builder for distutils2 to include all files under subversion control. The > problem with this is that different versions of subversion use different > file formats. If we want to use a manifest builder, then we will need to > run a subversion command rather than looking at the file system. > > At the moment I suggest using a manifest file. > > 2. Build. > > We don't actually build anything, but do run some translation utility > scripts in this phase. In distutils2, hooks are provided to run custom > scripts. In distutils and setuptools, custom scripts can be run by > sub-classing commands. > > 3. Installation. > > Installation involves copying files to the appropriate locations. It is > easy to specify where to install packages and package data. We did not > fully investigate how to handle resources. > > In disutils2, they introduced a concept of resources. The idea was that > you could specify a target such as {doc}. This would be substituted for > the location of documentation, which is OS dependent. We may need to > investigate how to define custom resource locations. > > > For more complex software, such as Gramps, distutils2 could do with some > more work. It is getting there, but not quickly. > > I'll get working what we have so far for you. > Ok. I would suggest copying trunk over the gep 26 branch, and then continue. Or delete the branch keeping the disutils stuff, and remaking it from trunk. Should it just work, we can merge it in trunk, and iron out remaining issues there. Benny > > Nick. > > > > On 20/09/12 16:25, Benny Malengier wrote: > >> Nick, >> >> With Rob gone, how to proceed with http://www.gramps-project.org/** >> wiki/index.php?title=GEPS_026:**_Replace_%27make%27_for_**Gramps_build<http://www.gramps-project.org/wiki/index.php?title=GEPS_026:_Replace_%27make%27_for_Gramps_build> >> Looking at that page, I don't see definite answers, more like a list of >> possible problems. >> You were involved with Rob in this if I remember correctly. Is distutils2 >> the way to go? >> If so, I would try to start that. I assume deleting all makefiles, and >> creating a setup.py is all that is needed. Then deciding if we need one or >> two packages (gramps/gen and rest). >> >> Benny >> > > |
From: Nick H. <nic...@ho...> - 2012-09-20 21:19:27
|
Benny, I have just refreshed my memory on GEPS 026. We have a prototype for both distutils and packaging (distutils2). 1. distutils This is currently in trunk and appears to work. It uses the setup.py and MANIFEST.in files. There is no need to delete the autotools files or rename the src directory. a. To create a source distribution run: python setup.py sdist It creates a tar file in dist directory. It also creates a MANIFEST file that contains files in distribution. b. To build run: python setup.py build Files are created in build directory. c. To install run: python setup.py install For testing it is convenient to install to a different root directory and disable execution of post-install mime processing. python setup.py install --root ~/test --enable-packager-mode 2. packaging (distutils2) The prototype for this is in the GEPS 026 branch. It uses the setup.cfg and custom_setup.py files. The src directory needs to be renamed to gramps in order for this to work. After a couple of tweaks to the setup.cfg file I managed to get this working in trunk. You will need to install distutils2 and the patch in bug #14651. a. To create a source distribution run: pysetup run sdist b. To build run: pysetup run build This will fail without the patch (bug #14651). c. To install run: pysetup run install_dist Testing is a pain because of a bug with --dry-run and a bug with --install-data. I suggest using the --home option. Also, I have not written an --enable-packager-mode option for distutils2 yet. There is no prototype for setuptools. The code has only been tested on Linux. I expect problems with other OS, in particular with file paths. Note: some paths need to be OS independent, but others need to be in Unix format (used in distutils configuration). More information for distutils2 can be found in the GEPS. Let me know if you need any help. Regards, Nick. On 20/09/12 19:20, Benny Malengier wrote: > > > 2012/9/20 Nick Hall <nic...@ho... > <mailto:nic...@ho...>> > > Benny, > > I was helping Rob. He was working on distutils2 which we should > be able to get working for Linux quite easily. > > There are 3 python options: > > 1. distutils > 2. setuptools > 3. packaging (distutils2) > > The most modern is packaging which should be included in the next > python release, but is available for earlier versions. It should > include some of the useful features of setuptools. > > These tools provide 3 main functions: > > 1. Source distribution. > > Files for distribution can be specified in a manifest file, in a > configuration file or by using a manifest builder. I wrote a > manifest builder for distutils2 to include all files under > subversion control. The problem with this is that different > versions of subversion use different file formats. If we want to > use a manifest builder, then we will need to run a subversion > command rather than looking at the file system. > > At the moment I suggest using a manifest file. > > 2. Build. > > We don't actually build anything, but do run some translation > utility scripts in this phase. In distutils2, hooks are provided > to run custom scripts. In distutils and setuptools, custom > scripts can be run by sub-classing commands. > > 3. Installation. > > Installation involves copying files to the appropriate locations. > It is easy to specify where to install packages and package data. > We did not fully investigate how to handle resources. > > In disutils2, they introduced a concept of resources. The idea > was that you could specify a target such as {doc}. This would be > substituted for the location of documentation, which is OS > dependent. We may need to investigate how to define custom > resource locations. > > > For more complex software, such as Gramps, distutils2 could do > with some more work. It is getting there, but not quickly. > > I'll get working what we have so far for you. > > > Ok. I would suggest copying trunk over the gep 26 branch, and then > continue. Or delete the branch keeping the disutils stuff, and > remaking it from trunk. > Should it just work, we can merge it in trunk, and iron out remaining > issues there. > > Benny > > > Nick. > > > > On 20/09/12 16:25, Benny Malengier wrote: > > Nick, > > With Rob gone, how to proceed with > http://www.gramps-project.org/wiki/index.php?title=GEPS_026:_Replace_%27make%27_for_Gramps_build > Looking at that page, I don't see definite answers, more like > a list of possible problems. > You were involved with Rob in this if I remember correctly. Is > distutils2 the way to go? > If so, I would try to start that. I assume deleting all > makefiles, and creating a setup.py is all that is needed. Then > deciding if we need one or two packages (gramps/gen and rest). > > Benny > > > |
From: Benny M. <ben...@gm...> - 2012-09-21 07:22:28
|
2012/9/20 Nick Hall <nic...@ho...> > Benny, > > I have just refreshed my memory on GEPS 026. We have a prototype for both > distutils and packaging (distutils2). > > 1. distutils > > This is currently in trunk and appears to work. It uses the setup.py and > MANIFEST.in files. There is no need to delete the autotools files or > rename the src directory. > > a. To create a source distribution run: > > python setup.py sdist > > It creates a tar file in dist directory. It also creates a MANIFEST file > that contains files in distribution. > > b. To build run: > > python setup.py build > > Files are created in build directory. > > c. To install run: > > python setup.py install > > For testing it is convenient to install to a different root directory and > disable execution of post-install mime processing. > > python setup.py install --root ~/test --enable-packager-mode > > > 2. packaging (distutils2) > > The prototype for this is in the GEPS 026 branch. It uses the setup.cfg > and custom_setup.py files. The src directory needs to be renamed to gramps > in order for this to work. > > After a couple of tweaks to the setup.cfg file I managed to get this > working in trunk. > > You will need to install distutils2 and the patch in bug #14651. > > a. To create a source distribution run: > > pysetup run sdist > > b. To build run: > > pysetup run build > > This will fail without the patch (bug #14651). > > c. To install run: > > pysetup run install_dist > > Testing is a pain because of a bug with --dry-run and a bug with > --install-data. I suggest using the --home option. > > Also, I have not written an --enable-packager-mode option for distutils2 > yet. > > There is no prototype for setuptools. The code has only been tested on > Linux. I expect problems with other OS, in particular with file paths. > Note: some paths need to be OS independent, but others need to be in Unix > format (used in distutils configuration). > > More information for distutils2 can be found in the GEPS. Let me know if > you need any help. > > Always annoying to have two choices. As you studied this most, please make a choice for distutils or distutils2. What I would like is: 1. If you do python setup.py install in the top directory, Gramps is installed in site-packages/gramps 2. We would like also a way however to only install core. This would be the gen and cli directory. Question is what to do with the plugins, as we want some plugins in such a core install also (specifically cli reports, docgen, ...). Perhaps we can just install all plugins also? Is such a setup possible? Or should we just have people install everything, and have a flag to setup.py to neglect errors in the gui code setup (I assume setup.py checks for needed libraries also?) 3. I would test it, but if it works, I plan to delete Makefiles. What use in keeping something around we don't want to maintain anymore? Benny |
From: Nick H. <nic...@ho...> - 2012-09-21 22:52:25
|
On 21/09/12 08:22, Benny Malengier wrote: > Always annoying to have two choices. As you studied this most, please > make a choice for distutils or distutils2. At present, distutils2 still has bugs, so we should use distutils. > What I would like is: > > 1. If you do > python setup.py install > in the top directory, Gramps is installed in site-packages/gramps Both of the prototypes install to a standard python location. > > 2. We would like also a way however to only install core. This would > be the gen and cli directory. Question is what to do with the plugins, > as we want some plugins in such a core install also (specifically cli > reports, docgen, ...). Perhaps we can just install all plugins also? This should be possible by creating a different configuration file, or adding options to the setup.py file. > > Is such a setup possible? Or should we just have people install > everything, and have a flag to setup.py to neglect errors in the gui > code setup (I assume setup.py checks for needed libraries also?) I don't know if setup.py checks for required libraries. > > 3. I would test it, but if it works, I plan to delete Makefiles. What > use in keeping something around we don't want to maintain anymore? It will need quite a lot of testing - I was leaving that to Rob. I expect there to be bugs on Windows and Mac installation. Some file paths are not in device independent format (some need to be in Unix format). We also need to check file locations for resource files. Nick. |
From: Benny M. <ben...@gm...> - 2012-09-29 18:31:32
|
Ok, important design decisions, so read following mail, or it is assumed you agree :-) I have been doing extra changes for the distutils install. Some things I think are needed (and I have done locally): 1/ also __init__.py files in the plugins directory. I don't like that plugins is all data while it is actually code. For the plugins distributed with gramps, adding __init__ does not seem like a problem 2/automatically scan plugins dir for some extra file types as data using os.walk 3/check on python version in setup.py You agree with this? After installing gramps however via setup.py, this is failing: benny@dell:~$ PYTHONPATH=/usr/local/lib/python2.7/site-packages:/home/benny/gramps/trunk/build/lib.linux-x86_64-2.7/ python Python 2.7.3 (default, Aug 1 2012, 05:14:39) [GCC 4.6.3] on linux2 >>> from gramps.gen.lib.date import date Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/benny/gramps/trunk/build/lib.linux-x86_64-2.7/gramps/gen/lib/__init__.py", line 27, in <module> from gen.lib.date import Date, DateError, Span ImportError: No module named gen.lib.date >>> So, this seems to indicate the only solution is to add to all our local imports gramps. also. Anybody knows a way around this? So, in the gen package, we do relative import of gen modules using .. import statement, while for import outside of gen package, we add gramps. in front of the import. Example changes: -from gen.ggettext import sgettext as _ -from gen.ggettext import ngettext +from ..ggettext import sgettext as _ and -from gen.lib.styledtexttagtype import StyledTextTagType +from styledtexttagtype import StyledTextTagType Comments on this? I think it is correct. Nick, I noted however that if I change code in const.py.in, the old const keeps on being used when doing python setup.py build Is this expected, or an error? Benny 2012/9/22 Nick Hall <nic...@ho...> > On 21/09/12 08:22, Benny Malengier wrote: > >> Always annoying to have two choices. As you studied this most, please >> make a choice for distutils or distutils2. >> > > At present, distutils2 still has bugs, so we should use distutils. > > > > What I would like is: >> >> 1. If you do >> python setup.py install >> in the top directory, Gramps is installed in site-packages/gramps >> > > Both of the prototypes install to a standard python location. > > > > >> 2. We would like also a way however to only install core. This would be >> the gen and cli directory. Question is what to do with the plugins, as we >> want some plugins in such a core install also (specifically cli reports, >> docgen, ...). Perhaps we can just install all plugins also? >> > > This should be possible by creating a different configuration file, or > adding options to the setup.py file. > > > > >> Is such a setup possible? Or should we just have people install >> everything, and have a flag to setup.py to neglect errors in the gui code >> setup (I assume setup.py checks for needed libraries also?) >> > > I don't know if setup.py checks for required libraries. > > > > >> 3. I would test it, but if it works, I plan to delete Makefiles. What use >> in keeping something around we don't want to maintain anymore? >> > > It will need quite a lot of testing - I was leaving that to Rob. > > I expect there to be bugs on Windows and Mac installation. Some file > paths are not in device independent format (some need to be in Unix > format). We also need to check file locations for resource files. > > Nick. > > |
From: Doug B. <dou...@gm...> - 2012-09-29 18:56:28
|
On Sat, Sep 29, 2012 at 2:31 PM, Benny Malengier <ben...@gm...> wrote: > Ok, important design decisions, so read following mail, or it is assumed you > agree :-) > > I have been doing extra changes for the distutils install. Some things I > think are needed (and I have done locally): > 1/ also __init__.py files in the plugins directory. I don't like that > plugins is all data while it is actually code. For the plugins distributed > with gramps, adding __init__ does not seem like a problem Would the __init__.py be there to actually allow the code to be imported and used, or just to make disutils happy? Currently we don't add "plugins" to the python search path, so I don't know if this will cause any conflicts (eg, finding a plugin instead of the gramps code). We would probably have to add__init__.py files in all the subdirs. It seems like this would be good to make it so that plugin code could also be used/reused in other ways. > 2/automatically scan plugins dir for some extra file types as data using > os.walk > 3/check on python version in setup.py Sounds fine. > You agree with this? > > After installing gramps however via setup.py, this is failing: > > benny@dell:~$ > PYTHONPATH=/usr/local/lib/python2.7/site-packages:/home/benny/gramps/trunk/build/lib.linux-x86_64-2.7/ > python > Python 2.7.3 (default, Aug 1 2012, 05:14:39) > [GCC 4.6.3] on linux2 >>>> from gramps.gen.lib.date import date > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File > "/home/benny/gramps/trunk/build/lib.linux-x86_64-2.7/gramps/gen/lib/__init__.py", > line 27, in <module> > from gen.lib.date import Date, DateError, Span > ImportError: No module named gen.lib.date >>>> > > So, this seems to indicate the only solution is to add to all our local > imports gramps. also. Anybody knows a way around this? I think with Python 2.x we need to either make it relative (in lib use "from date import Date, DateError, Span") or absolute (from anywhere "from gramps.gen.lib.date import Date, DateError, Span"). In Python 3, I think that there are different ways using a dot before the lib name ("from .date import Date, DateError, Span"). Not sure about that. > So, in the gen package, we do relative import of gen modules using .. import > statement, while for import outside of gen package, we add gramps. in front > of the import. > Example changes: > -from gen.ggettext import sgettext as _ > -from gen.ggettext import ngettext > +from ..ggettext import sgettext as _ > > and > > -from gen.lib.styledtexttagtype import StyledTextTagType > +from styledtexttagtype import StyledTextTagType > > Comments on this? I think it is correct. Yes, I think that is right. You could (alternatively) add "gramps" to the Python search path, but that would be consider bad practice. > Nick, I noted however that if I change code in const.py.in, the old const > keeps on being used when doing BTW, I think we can get rid of "const.py.in". The only useful bit in there is to add the SVN revision number to the Gramps version number, but there is code in trunk (./src/gen/utils/svn.py) now that can do that on the fly. -Doug > python setup.py build > > Is this expected, or an error? > > Benny > > > > > 2012/9/22 Nick Hall <nic...@ho...> >> >> On 21/09/12 08:22, Benny Malengier wrote: >>> >>> Always annoying to have two choices. As you studied this most, please >>> make a choice for distutils or distutils2. >> >> >> At present, distutils2 still has bugs, so we should use distutils. >> >> >> >>> What I would like is: >>> >>> 1. If you do >>> python setup.py install >>> in the top directory, Gramps is installed in site-packages/gramps >> >> >> Both of the prototypes install to a standard python location. >> >> >> >>> >>> 2. We would like also a way however to only install core. This would be >>> the gen and cli directory. Question is what to do with the plugins, as we >>> want some plugins in such a core install also (specifically cli reports, >>> docgen, ...). Perhaps we can just install all plugins also? >> >> >> This should be possible by creating a different configuration file, or >> adding options to the setup.py file. >> >> >> >>> >>> Is such a setup possible? Or should we just have people install >>> everything, and have a flag to setup.py to neglect errors in the gui code >>> setup (I assume setup.py checks for needed libraries also?) >> >> >> I don't know if setup.py checks for required libraries. >> >> >> >>> >>> 3. I would test it, but if it works, I plan to delete Makefiles. What use >>> in keeping something around we don't want to maintain anymore? >> >> >> It will need quite a lot of testing - I was leaving that to Rob. >> >> I expect there to be bugs on Windows and Mac installation. Some file >> paths are not in device independent format (some need to be in Unix format). >> We also need to check file locations for resource files. >> >> Nick. >> > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2012-09-29 19:55:28
|
2012/9/29 Doug Blank <dou...@gm...> > On Sat, Sep 29, 2012 at 2:31 PM, Benny Malengier > <ben...@gm...> wrote: > > Ok, important design decisions, so read following mail, or it is assumed > you > > agree :-) > > > > I have been doing extra changes for the distutils install. Some things I > > think are needed (and I have done locally): > > 1/ also __init__.py files in the plugins directory. I don't like that > > plugins is all data while it is actually code. For the plugins > distributed > > with gramps, adding __init__ does not seem like a problem > > Would the __init__.py be there to actually allow the code to be > imported and used, or just to make disutils happy? Currently we don't > add "plugins" to the python search path, so I don't know if this will > cause any conflicts (eg, finding a plugin instead of the gramps code). > We would probably have to add__init__.py files in all the subdirs. It > seems like this would be good to make it so that plugin code could > also be used/reused in other ways. > Yes, we did not want to reuse plugin code. So we introduced lib, which is not the best of constructs in my opinion. I see Serge already added an __init__ to his maps subdir in lib. I don't know if it would be possible to find a plugin. Should I add in the __init__ for safety: __all__ = [] ?? > > Nick, I noted however that if I change code in const.py.in, the old > const > > keeps on being used when doing > > > BTW, I think we can get rid of "const.py.in". The only useful bit in > there is to add the SVN revision number to the Gramps version number, > but there is code in trunk (./src/gen/utils/svn.py) now that can do > that on the fly. > > Perhaps that is best, but officially for prefix we still need it. The translation piece uses prefix as fallback, don't know if anybody actually uses that though ... Version is indeed completely broken in const.py, after I update it for distutils, it would be great if you deprecate version there (version_tuple is hardcoded already anyway, and there is an ugly hack for windows there which hardcodes version also). We also have version duplicate in setup.py now by the way. The reason const.py does not work with build, is that the write_const_py function is not called for build in setup.py. It is not called, because @prefix@ is not known when in build, it only is set when install. As a consequence, build does not know it is /usr/local. Which is normal, when you do build, the path will be something like: ~/gramps/trunk/build/lib.linux-x86_64-2.7 So, I have an ugly hack for that that works fine: do like in windows when build: if hasattr(install_cmd, 'install_data'): #during install prefix = "'%s'" % install_cmd.install_data sysconfdir = "'%s'" % os.path.join(install_cmd.install_data, 'etc') else: #in build prefix = 'os.path.join(os.path.dirname(__file__), os.pardir)' sysconfdir = prefix + ' + "' + os.sep + 'etc"' # Is this correct? subst_vars = ((u'@VERSIONSTRING@', VERSION), (u'"@prefix@"', prefix), (u'"@sysconfdir@"', sysconfdir)) If nobody has better idea, I'll proceed like that. Benny |
From: Benny M. <ben...@gm...> - 2012-10-04 08:31:51
|
Nick, I think we can set the GEP on finished. Issues with packaging will be handled I assume when packagers actually try to create packages for their distro's. Can you determine please for yourself what you want to backup/keep from the GEP branch in subversion, and then delete the branch, as per the GEP policy? Note that I would want to aim for support for python 3.2 or 3.3 in trunk. So perhaps we will need some of the distutils2 work again to install with python 3.x? Benny |
From: Nick H. <nic...@ho...> - 2012-10-04 15:54:00
|
On 04/10/12 09:31, Benny Malengier wrote: > Nick, > > I think we can set the GEP on finished. Issues with packaging will be > handled I assume when packagers actually try to create packages for > their distro's. > > Can you determine please for yourself what you want to backup/keep > from the GEP branch in subversion, and then delete the branch, as per > the GEP policy? I have now removed the GEPS 026 branch. The files setup.cfg and setup_custom.py have been attached the following: 6093: GEPS 026: Replace distutils by packaging (distutils2) http://www.gramps-project.org/bugs/view.php?id=6093 This contains instructions for installing distutils2 and running it in trunk. > > Note that I would want to aim for support for python 3.2 or 3.3 in > trunk. So perhaps we will need some of the distutils2 work again to > install with python 3.x? The latest release of distutils2 is 1.0a4, which only works with a patch. We have code that works with distutils2, but I don't suggest we use it until either the packaging module is released (in 3.3?) or the bug is fixed. It now works in trunk with the files attached to #6093. Nick. > > > Benny |
From: Benny M. <ben...@gm...> - 2012-10-04 19:13:49
|
2012/10/4 Nick Hall <nic...@ho...> > On 04/10/12 09:31, Benny Malengier wrote: > >> Nick, >> >> I think we can set the GEP on finished. Issues with packaging will be >> handled I assume when packagers actually try to create packages for their >> distro's. >> >> Can you determine please for yourself what you want to backup/keep from >> the GEP branch in subversion, and then delete the branch, as per the GEP >> policy? >> > > I have now removed the GEPS 026 branch. > > The files setup.cfg and setup_custom.py have been attached the following: > > 6093: GEPS 026: Replace distutils by packaging (distutils2) > > http://www.gramps-project.org/**bugs/view.php?id=6093<http://www.gramps-project.org/bugs/view.php?id=6093> > > This contains instructions for installing distutils2 and running it in > trunk. > > > > >> Note that I would want to aim for support for python 3.2 or 3.3 in trunk. >> So perhaps we will need some of the distutils2 work again to install with >> python 3.x? >> > > The latest release of distutils2 is 1.0a4, which only works with a patch. > We have code that works with distutils2, but I don't suggest we use it > until either the packaging module is released (in 3.3?) or the bug is fixed. > Good work. I don't see anything in python 3.3 release of last week: http://docs.python.org/py3k/whatsnew/3.3.htm I think 3.4 is only for 2014. As python 3.3 allows the use of u'string', it might be the easiest to target that as the python 3.x that is supported for gramps. I wonder if ubuntu 12.10 will already have python 3.3 Benny > It now works in trunk with the files attached to #6093. > > Nick. > f > > >> >> Benny >> > > |
From: Serge N. <Ser...@fr...> - 2012-10-04 19:51:51
|
Le 04/10/2012 21:13, Benny Malengier a écrit : > > > 2012/10/4 Nick Hall <nic...@ho... <mailto:nic...@ho...>> > > On 04/10/12 09:31, Benny Malengier wrote: > > Nick, > > I think we can set the GEP on finished. Issues with packaging will be handled I assume when packagers actually try to create packages for their distro's. > > Can you determine please for yourself what you want to backup/keep from the GEP branch in subversion, and then delete the branch, as per the GEP policy? > > > I have now removed the GEPS 026 branch. > > The files setup.cfg and setup_custom.py have been attached the following: > > 6093: GEPS 026: Replace distutils by packaging (distutils2) > > http://www.gramps-project.org/bugs/view.php?id=6093 > > This contains instructions for installing distutils2 and running it in trunk. > > > > > Note that I would want to aim for support for python 3.2 or 3.3 in trunk. So perhaps we will need some of the distutils2 work again to install with python 3.x? > > > The latest release of distutils2 is 1.0a4, which only works with a patch. We have code that works with distutils2, but I don't suggest we use it until either the packaging module is released (in 3.3?) or the bug is fixed. > > > Good work. I don't see anything in python 3.3 release of last week: http://docs.python.org/py3k/whatsnew/3.3.htm > I think 3.4 is only for 2014. > As python 3.3 allows the use of u'string', it might be the easiest to target that as the python 3.x that is supported for gramps. I wonder if ubuntu 12.10 will already have python 3.3 Yes 12.10 has : python3.3 ( 3.3.0-1) libpython3.3-stdlib > > Benny > > > It now works in trunk with the files attached to #6093. > > Nick. > f > > > > Benny > |
From: Nick H. <nic...@ho...> - 2012-10-04 21:30:42
|
On 04/10/12 20:51, Serge Noiraud wrote: >> Good work. I don't see anything in python 3.3 release of last week: >> http://docs.python.org/py3k/whatsnew/3.3.htm >> I think 3.4 is only for 2014. >> As python 3.3 allows the use of u'string', it might be the easiest to >> target that as the python 3.x that is supported for gramps. I wonder >> if ubuntu 12.10 will already have python 3.3 > Yes 12.10 has : > python3.3 ( 3.3.0-1) > libpython3.3-stdlib >> I just tried to import the packaging module. It doesn't look like distutils2 made it into 3.3. Not much active development is going on either. Nick. |
From: Benny M. <ben...@gm...> - 2012-10-05 07:21:53
|
2012/10/4 Nick Hall <nic...@ho...> > On 04/10/12 20:51, Serge Noiraud wrote: > >> Good work. I don't see anything in python 3.3 release of last week: > >> http://docs.python.org/py3k/whatsnew/3.3.htm > >> I think 3.4 is only for 2014. > >> As python 3.3 allows the use of u'string', it might be the easiest to > >> target that as the python 3.x that is supported for gramps. I wonder > >> if ubuntu 12.10 will already have python 3.3 > > Yes 12.10 has : > > python3.3 ( 3.3.0-1) > > libpython3.3-stdlib > >> > > I just tried to import the packaging module. It doesn't look like > distutils2 made it into 3.3. > > Not much active development is going on either. > distutils is still present, http://docs.python.org/py3k/library/distutils.html#module-distutils, so there is no problem I think. Benny > > Nick. > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2012-10-05 11:48:20
|
On 05/10/12 08:21, Benny Malengier wrote: > distutils is still present, > http://docs.python.org/py3k/library/distutils.html#module-distutils, > so there is no problem I think. Yes. The packaging (disutils2) module is planned to replace distutils. The target was for v3.3 but they obviously missed it. Also, there seems to be no active development on packaging any more. Nick. |
From: jerome <rom...@ya...> - 2012-10-05 12:29:18
|
http://mail.python.org/pipermail/python-dev/2012-June/120430.html There is also comments (in french) about this on http://linuxfr.org/news/python-3-3-est-sorti --- En date de : Ven 5.10.12, Nick Hall <nic...@ho...> a écrit : > De: Nick Hall <nic...@ho...> > Objet: Re: [Gramps-devel] replace make > À: "Benny Malengier" <ben...@gm...> > Cc: gra...@li... > Date: Vendredi 5 octobre 2012, 13h48 > On 05/10/12 08:21, Benny Malengier > wrote: > > distutils is still present, > > http://docs.python.org/py3k/library/distutils.html#module-distutils, > > > so there is no problem I think. > > Yes. The packaging (disutils2) module is planned to replace > distutils. > The target was for v3.3 but they obviously missed it. > > Also, there seems to be no active development on packaging > any more. > > Nick. > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy > New Relic APM > Deploy New Relic app performance management and know > exactly > what is happening inside your Ruby, Python, PHP, Java, and > .NET app > Try New Relic at no cost today and get our sweet Data Nerd > shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |