Quantcast

What blocks us for 4.0

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

What blocks us for 4.0

Benny Malengier
For an actual 4.0.0 release we still need some things.

1/what to do with 'pyexiv2 module not loaded' in python3? Nick, what do you advice?

2/PIL not present in python3. Do I try that pillow code? John, as you know PIL somewhat, advice? If the API is the same, a switch based on python version would be easy.

3/I don't have geography working at the moment but mailed Serge about that. Probably a non 100% feature complete like 3.4 Geography is the biggest problem?

I think all other problems with the conversions have been worked around. Gtkspell did the release we need in the meantime, so that is also ok.
Or did I forget something?

If those issues are done, I would switch up to beta version after the next alpha.

Greetings,
Benny

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Nick Hall-6
On 12/01/13 15:34, Benny Malengier wrote:
> 1/what to do with 'pyexiv2 module not loaded' in python3? Nick, what
> do you advice?

If people want to use the image metadata gramplets they will have to use
python 2.7.

The pyexiv2 module is optional - if you don't have it installed you will
get a warning that certain functionality is unavailable.  I suggest
moving it from the "strongly recommended" to the "optional" section in
the README.

I would like to keep the Metadata Viewer in core Gramps, but I wouldn't
mind moving the Edit Image Metadata gramplet into gramps-addons.  A
couple of people pointed out that there is other software available for
editing metadata.

In the future I would like to develop better integration of image
metadata with genealogical data.

Nick.


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

John Ralls-2
In reply to this post by Benny Malengier

On Jan 12, 2013, at 7:34 AM, Benny Malengier <[hidden email]> wrote:

> For an actual 4.0.0 release we still need some things.
>
> 1/what to do with 'pyexiv2 module not loaded' in python3? Nick, what do you advice?
>
> 2/PIL not present in python3. Do I try that pillow code? John, as you know PIL somewhat, advice? If the API is the same, a switch based on python version would be easy.
>
> 3/I don't have geography working at the moment but mailed Serge about that. Probably a non 100% feature complete like 3.4 Geography is the biggest problem?
>
> I think all other problems with the conversions have been worked around. Gtkspell did the release we need in the meantime, so that is also ok.
> Or did I forget something?
>
> If those issues are done, I would switch up to beta version after the next alpha.


We don't need Py3 to release. Py2 is available everywhere.  Don't worry about it. The few people who care can get the py3 forks from the respective repos and roll their own.

I've been using Serge's fork of osmgpsmap, which works fine. That's been pulled into Stower's master, so the only thing we need is for him to do a release so that the distros will pick it up.

Has anyone run the test suite? I tried briefly and failed, so I set that aside for later. I think we should have all tests passing before we declare beta (I'm not saying they don't, just that it didn't work for me.) `setup.py check` appears to be a no-op.

Regards,
John Ralls


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Benny Malengier

2013/1/12 John Ralls <[hidden email]>
Has anyone run the test suite? I tried briefly and failed, so I set that aside for later. I think we should have all tests passing before we declare beta (I'm not saying they don't, just that it didn't work for me.) `setup.py check` appears to be a no-op.

We don't have a test suite.
In 3.0 there was an attempt to make it by Jim. Some tests where added, I don't know which.
http://www.gramps-project.org/wiki/index.php?title=Unit_Test_Quickstart
http://gramps.1791082.n4.nabble.com/unit-testing-review-and-recommendations-td1797000.html

As Brian there writes: "I think you have hit the nail on the head. You no longer need to build consensus about whether to do unit testing. You already have that. Now, you just need to keep people involved as you implement it. Transparency is the key. I think that between using the Wiki, and taking small steps, you will be fine. "

The above did not materialize. No need to blame anyone, this is OSS and starting a testing suite for a program like Gramps is probably not an easy task.

Some developers used what was made and added extra tests I think, but the devel list has never been notified about how to use the test suite or expand it. That mail thread above is already too dense for me to follow.

So, as the test suite has never been run to do a release, we can hardly start now. I would like it very much if we had a test suite, but that would require a developer that starts a framework for that according to his owns plans and experience, and then posts to devel list some simple commands and some simple example to show how it is done and can be used.

I'm curious actually to what command you ran. Like that wiki page says, 'python module_test.py -v' on some python files in '/test' dirs?

Benny

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

John Ralls-2

On Jan 12, 2013, at 3:10 PM, Benny Malengier <[hidden email]> wrote:

>
> 2013/1/12 John Ralls <[hidden email]>
> Has anyone run the test suite? I tried briefly and failed, so I set that aside for later. I think we should have all tests passing before we declare beta (I'm not saying they don't, just that it didn't work for me.) `setup.py check` appears to be a no-op.
>
> We don't have a test suite.
> In 3.0 there was an attempt to make it by Jim. Some tests where added, I don't know which.
> http://www.gramps-project.org/wiki/index.php?title=Unit_Test_Quickstart
> http://gramps.1791082.n4.nabble.com/unit-testing-review-and-recommendations-td1797000.html
>
> As Brian there writes: "I think you have hit the nail on the head. You no longer need to build consensus about whether to do unit testing. You already have that. Now, you just need to keep people involved as you implement it. Transparency is the key. I think that between using the Wiki, and taking small steps, you will be fine. "
>
> The above did not materialize. No need to blame anyone, this is OSS and starting a testing suite for a program like Gramps is probably not an easy task.
>
> Some developers used what was made and added extra tests I think, but the devel list has never been notified about how to use the test suite or expand it. That mail thread above is already too dense for me to follow.
>
> So, as the test suite has never been run to do a release, we can hardly start now. I would like it very much if we had a test suite, but that would require a developer that starts a framework for that according to his owns plans and experience, and then posts to devel list some simple commands and some simple example to show how it is done and can be used.
>
> I'm curious actually to what command you ran. Like that wiki page says, 'python module_test.py -v' on some python files in '/test' dirs?
>

Oh. That's disappointing. I've made a lot of changes throughout the codebase and I'd hoped that there'd be at least some testing in place to exercise it short of manually trying every view and every report.

Thanks for the links. That thread was a long time ago.

I tried RunAllTests.py and runtest.sh. Neither worked in python3, but if nobody here is interested in testing, I guess I shouldn't be surprised that they're not ported.

Regards,
John Ralls



------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Paul Franklin-5
In reply to this post by John Ralls-2
On 1/12/13, John Ralls <[hidden email]> wrote:

> We don't need Py3 to release. Py2 is available everywhere.  Don't worry
> about it. The few people who care can get the py3 forks from the respective
> repos and roll their own.

We might consider making Python 2.7 the mandatory one and Python 3
the "optional" one, perhaps mentioning in the README that Python 3
paths are less likely to have been thoroughly tested.

I know that Benny has put an immense amount of work into making
it all work on Python 3, and will probably be very disappointed, but
it also seems to me that changes are being discovered all the time
(division changes, string/unicode changes, encoding changes, etc.),
every time somebody tries a code path under Python3 which has not
yet been tried.

Perhaps this would make it easier to have it on Windows also, I am
not sure.  But I don't think we should forget our Windows users, since
I am guessing they are the majority.

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Benny Malengier



2013/1/13 Paul Franklin <[hidden email]>
On 1/12/13, John Ralls <[hidden email]> wrote:

> We don't need Py3 to release. Py2 is available everywhere.  Don't worry
> about it. The few people who care can get the py3 forks from the respective
> repos and roll their own.

We might consider making Python 2.7 the mandatory one and Python 3
the "optional" one, perhaps mentioning in the README that Python 3
paths are less likely to have been thoroughly tested.

I know that Benny has put an immense amount of work into making
it all work on Python 3, and will probably be very disappointed, but
it also seems to me that changes are being discovered all the time
(division changes, string/unicode changes, encoding changes, etc.),
every time somebody tries a code path under Python3 which has not
yet been tried.

Perhaps this would make it easier to have it on Windows also, I am
not sure.  But I don't think we should forget our Windows users, since
I am guessing they are the majority.

Although you are right, packagers often don't want every year to redesign their spec files or build system. As they will have a lot of work for gramps 4.0, doing it immediately for python3 and being good for the coming years, has advantages for them.
Nevertheless, for packagers, it should be easy to create a gramps in python3 and a gramps2 in python2. It is up to them what they actually do.

Main point as I see it is that in the very near future, developers will no longer test python2 code path, as in 2013 most distributions will have python pointing to python3. So although python2 is the safe bet at the moment, this will change very fast. As the original idea to have 4.0 unstable only is no longer going through, I don't mind indicating in the README that python2 will normally be the more stable option for 4.0

About windows, as Helge shows, the system there is not ready for 4.0, which is the reason 3.4 will be supported longer. Programs like Gramps moving forward is exactly what is needed to fix the issues on Windows.

Benny

 

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

John Ralls-2

On Jan 13, 2013, at 9:11 AM, Benny Malengier <[hidden email]> wrote:




2013/1/13 Paul Franklin <[hidden email]>
On 1/12/13, John Ralls <[hidden email]> wrote:

> We don't need Py3 to release. Py2 is available everywhere.  Don't worry
> about it. The few people who care can get the py3 forks from the respective
> repos and roll their own.

We might consider making Python 2.7 the mandatory one and Python 3
the "optional" one, perhaps mentioning in the README that Python 3
paths are less likely to have been thoroughly tested.

I know that Benny has put an immense amount of work into making
it all work on Python 3, and will probably be very disappointed, but
it also seems to me that changes are being discovered all the time
(division changes, string/unicode changes, encoding changes, etc.),
every time somebody tries a code path under Python3 which has not
yet been tried.

Perhaps this would make it easier to have it on Windows also, I am
not sure.  But I don't think we should forget our Windows users, since
I am guessing they are the majority.

Although you are right, packagers often don't want every year to redesign their spec files or build system. As they will have a lot of work for gramps 4.0, doing it immediately for python3 and being good for the coming years, has advantages for them.
Nevertheless, for packagers, it should be easy to create a gramps in python3 and a gramps2 in python2. It is up to them what they actually do.

Main point as I see it is that in the very near future, developers will no longer test python2 code path, as in 2013 most distributions will have python pointing to python3. So although python2 is the safe bet at the moment, this will change very fast. As the original idea to have 4.0 unstable only is no longer going through, I don't mind indicating in the README that python2 will normally be the more stable option for 4.0

About windows, as Helge shows, the system there is not ready for 4.0, which is the reason 3.4 will be supported longer. Programs like Gramps moving forward is exactly what is needed to fix the issues on Windows.


Nope. Not happening,. GObject-Introspection doesn't work with python3 [1].  Neither does libxml2 or libxslt, so Gtk-doc doesn't, either.

Just out of curiosity, look through Ubuntu admin scripts written in python and see if they've all been ported. 

You seem to be under the impression [2] that most distributions are going to be able to support running Gramps4. That's absolutely not the case. As of today, only the bleeding-edge distributions like Ubuntu and Arch can run Gramps 4 without the user having to build a Gtk stack from source. It appears that Fedora 18, to be released Tuesday, will. Debian unstable (Sid), which won't be released as stable for 2 years, is still on pygobject 3.2.2. RHEL 6 doesn't even support Gtk3 at all, though that costs money and it's likely that few Gramps users will pay for it. OpenSuse is currently on 3.2.2, though they have an RPM for 3.4.2 in their repo that might make it into 12.3 in March; otherwise it has to wait for 13 in November. Aunt Martha isn't running Arch. If she isn't on M$Win, she's probably on Fedora 16 or Suse 11.

Regards,
John Ralls


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Benny Malengier



2013/1/13 John Ralls <[hidden email]>

On Jan 13, 2013, at 9:11 AM, Benny Malengier <[hidden email]> wrote:




2013/1/13 Paul Franklin <[hidden email]>
On 1/12/13, John Ralls <[hidden email]> wrote:

> We don't need Py3 to release. Py2 is available everywhere.  Don't worry
> about it. The few people who care can get the py3 forks from the respective
> repos and roll their own.

We might consider making Python 2.7 the mandatory one and Python 3
the "optional" one, perhaps mentioning in the README that Python 3
paths are less likely to have been thoroughly tested.

I know that Benny has put an immense amount of work into making
it all work on Python 3, and will probably be very disappointed, but
it also seems to me that changes are being discovered all the time
(division changes, string/unicode changes, encoding changes, etc.),
every time somebody tries a code path under Python3 which has not
yet been tried.

Perhaps this would make it easier to have it on Windows also, I am
not sure.  But I don't think we should forget our Windows users, since
I am guessing they are the majority.

Although you are right, packagers often don't want every year to redesign their spec files or build system. As they will have a lot of work for gramps 4.0, doing it immediately for python3 and being good for the coming years, has advantages for them.
Nevertheless, for packagers, it should be easy to create a gramps in python3 and a gramps2 in python2. It is up to them what they actually do.

Main point as I see it is that in the very near future, developers will no longer test python2 code path, as in 2013 most distributions will have python pointing to python3. So although python2 is the safe bet at the moment, this will change very fast. As the original idea to have 4.0 unstable only is no longer going through, I don't mind indicating in the README that python2 will normally be the more stable option for 4.0

About windows, as Helge shows, the system there is not ready for 4.0, which is the reason 3.4 will be supported longer. Programs like Gramps moving forward is exactly what is needed to fix the issues on Windows.


Nope. Not happening,. GObject-Introspection doesn't work with python3 [1].  Neither does libxml2 or libxslt, so Gtk-doc doesn't, either.

And what does that mean? Is GTK indicating they are no longer interested in having their toolkit work on Windows?
We are not dropping python 2 support,  so it is not really an issue. As I understand, python 3 for Mac is also not ready. Linux has always been the core system of Gramps, and python3 there is fully supported.

Just out of curiosity, look through Ubuntu admin scripts written in python and see if they've all been ported.

Next LTS should be python3 only, so they are certainly working on it: https://wiki.ubuntu.com/Python/3
As you say, Arch also, I believe my friend does not even have python2 :-)
Anyway, python 2 is fully supported, so this is only an indication in which direction things are moving.

You seem to be under the impression [2] that most distributions are going to be able to support running Gramps4. That's absolutely not the case. As of today, only the bleeding-edge distributions like Ubuntu and Arch can run Gramps 4 without the user having to build a Gtk stack from source. It appears that Fedora 18, to be released Tuesday, will. Debian unstable (Sid), which won't be released as stable for 2 years, is still on pygobject 3.2.2. RHEL 6 doesn't even support Gtk3 at all, though that costs money and it's likely that few Gramps users will pay for it. OpenSuse is currently on 3.2.2, though they have an RPM for 3.4.2 in their repo that might make it into 12.3 in March; otherwise it has to wait for 13 in November. Aunt Martha isn't running Arch. If she isn't on M$Win, she's probably on Fedora 16 or Suse 11.

All true. The only reason we can use Gramps 4 on Ubuntu 12.10 is because we tried to port Gramps for Ubuntu 11.10, hit a bug, posted bug, and had bug fixed in 3.3.2. Without this fix, actual coding of generic listviews is impossible.
So, one could claim we can use Gramps 4 because we pushed forward in the first place. Those new releases not picking it up indicates something about their governance and the desires of their communities. If you look at the release logs of pygobject, then it is very clear the changes there are not about minor issues, but about core functionality that was missing. Effectively, not shipping a recent pygobject is like shipping beta or even alpha software. Should Gramps users of those distributions post bug tickets that their favourite program cannot run, they might fix it.

I have no qualms personally to indicate to an opensuse or fedora user they should switch to Ubuntu for Gramps use if those distro's would making running recent Gramps too hard for the common user. Linux development has chosen for non-complete installers, so distributions must make that possible or fall in disuse.

Greetings,
Benny

 


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

John Ralls-2

On Jan 13, 2013, at 1:56 PM, Benny Malengier <[hidden email]> wrote:

>
>
>
> 2013/1/13 John Ralls <[hidden email]>
>
>> On Jan 13, 2013, at 9:11 AM, Benny Malengier <[hidden email]> wrote:
>>
>>>
>>>
>>>
>>> 2013/1/13 Paul Franklin <[hidden email]>
>>> On 1/12/13, John Ralls <[hidden email]> wrote:
>>>
>>> > We don't need Py3 to release. Py2 is available everywhere.  Don't worry
>>> > about it. The few people who care can get the py3 forks from the respective
>>> > repos and roll their own.
>>>
>>> We might consider making Python 2.7 the mandatory one and Python 3
>>> the "optional" one, perhaps mentioning in the README that Python 3
>>> paths are less likely to have been thoroughly tested.
>>>
>>> I know that Benny has put an immense amount of work into making
>>> it all work on Python 3, and will probably be very disappointed, but
>>> it also seems to me that changes are being discovered all the time
>>> (division changes, string/unicode changes, encoding changes, etc.),
>>> every time somebody tries a code path under Python3 which has not
>>> yet been tried.
>>>
>>> Perhaps this would make it easier to have it on Windows also, I am
>>> not sure.  But I don't think we should forget our Windows users, since
>>> I am guessing they are the majority.
>>>
>>> Although you are right, packagers often don't want every year to redesign their spec files or build system. As they will have a lot of work for gramps 4.0, doing it immediately for python3 and being good for the coming years, has advantages for them.
>>> Nevertheless, for packagers, it should be easy to create a gramps in python3 and a gramps2 in python2. It is up to them what they actually do.
>>>
>>> Main point as I see it is that in the very near future, developers will no longer test python2 code path, as in 2013 most distributions will have python pointing to python3. So although python2 is the safe bet at the moment, this will change very fast. As the original idea to have 4.0 unstable only is no longer going through, I don't mind indicating in the README that python2 will normally be the more stable option for 4.0
>>>
>>> About windows, as Helge shows, the system there is not ready for 4.0, which is the reason 3.4 will be supported longer. Programs like Gramps moving forward is exactly what is needed to fix the issues on Windows.
>>>
>>
>> Nope. Not happening,. GObject-Introspection doesn't work with python3 [1].  Neither does libxml2 or libxslt, so Gtk-doc doesn't, either.
>>
> And what does that mean? Is GTK indicating they are no longer interested in having their toolkit work on Windows?
> We are not dropping python 2 support,  so it is not really an issue. As I understand, python 3 for Mac is also not ready. Linux has always been the core system of Gramps, and python3 there is fully supported.

It means that until GObject-Introspection is updated to build with py3, distros have the choice of either continuing to include py2 or dropping Gtk's introspection support.

>
>> Just out of curiosity, look through Ubuntu admin scripts written in python and see if they've all been ported.
>>
> Next LTS should be python3 only, so they are certainly working on it: https://wiki.ubuntu.com/Python/3
> As you say, Arch also, I believe my friend does not even have python2 :-)
> Anyway, python 2 is fully supported, so this is only an indication in which direction things are moving.
Hmm. So packagers are going to run py2 to get GObject-Introspection going but leave it out of the distro? Or maybe they're just going to drop GObject-Introspection entirely. I don't know what other projects use it, but all of the major ones (GIMP, Inkscape, etc.) are in C and don't care a bit about introspection or pygobject.

Do you think that even Ubuntu will support unreleased dependencies like the PIL and PyExiv2 py3 forks?

>
>> You seem to be under the impression [2] that most distributions are going to be able to support running Gramps4. That's absolutely not the case. As of today, only the bleeding-edge distributions like Ubuntu and Arch can run Gramps 4 without the user having to build a Gtk stack from source. It appears that Fedora 18, to be released Tuesday, will. Debian unstable (Sid), which won't be released as stable for 2 years, is still on pygobject 3.2.2. RHEL 6 doesn't even support Gtk3 at all, though that costs money and it's likely that few Gramps users will pay for it. OpenSuse is currently on 3.2.2, though they have an RPM for 3.4.2 in their repo that might make it into 12.3 in March; otherwise it has to wait for 13 in November. Aunt Martha isn't running Arch. If she isn't on M$Win, she's probably on Fedora 16 or Suse 11.
>>
> All true. The only reason we can use Gramps 4 on Ubuntu 12.10 is because we tried to port Gramps for Ubuntu 11.10, hit a bug, posted bug, and had bug fixed in 3.3.2. Without this fix, actual coding of generic listviews is impossible.

> So, one could claim we can use Gramps 4 because we pushed forward in the first place. Those new releases not picking it up indicates something about their governance and the desires of their communities. If you look at the release logs of pygobject, then it is very clear the changes there are not about minor issues, but about core functionality that was missing. Effectively, not shipping a recent pygobject is like shipping beta or even alpha software. Should Gramps users of those distributions post bug tickets that their favourite program cannot run, they might fix it.

>
> I have no qualms personally to indicate to an opensuse or fedora user they should switch to Ubuntu for Gramps use if those distro's would making running recent Gramps too hard for the common user. Linux development has chosen for non-complete installers, so distributions must make that possible or fall in disuse.

The difference is that Ubuntu totally trusts upstream to handle QC, and more conservative distros test for themselves. That takes time.

I doubt that many people select a distro based on whether it will run Gramps, and if Gramps4 doesn't work on a distro, then they'll package 3.4. They won't tell us about it.

But based on downloads [1], 71% of our 3.4.2 users are on MSWin, 15% on OSX, and 14% on Linux. Note that 3.4.2 is too recent even to be included in Ubuntu 12-10 and probably anywhere else, so that's a pretty good representation of people who care enough to go seek out a new version.

[1] https://sourceforge.net/projects/gramps/files/Stable/3.4.2/stats/os?dates=2012-10-28 to 2013-01-13
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Benny Malengier

2013/1/14 John Ralls <[hidden email]>

But based on downloads [1], 71% of our 3.4.2 users are on MSWin, 15% on OSX, and 14% on Linux. Note that 3.4.2 is too recent even to be included in Ubuntu 12-10 and probably anywhere else, so that's a pretty good representation of people who care enough to go seek out a new version.

What are we actually discussing about? Software gets adapted to new technologies, people are still happy with the old ones, people only upgrade if a certain bug or feature is really annoying or something they want and seek out.
For me it was not needed to deprecate pygtk, but that was done, and we have to live with it.

This discussion is not really going in a direction, just stating facts. Gramps 4.0 has hardly any new features compared to 3.4, so our 3.4 users are good till 2014 anyway by design, by which time I hope having Gramps 4.0 out and other programs based on the same technologies, causes some people who care about their platform to submit patches against the problematic code bases. If there are no programs using gi with python3, there is also little push to fix that issue, that has always been the nature of OSS.

There is not much more we can do, pygtk and python2 will go the way of dodo no matter what. Did we prepare too soon for that? Perhaps. Personally, I hate technology changes as it stops us from having time for real features, so I'm always happy when they're done.

Benny

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

enno
In reply to this post by John Ralls-2
Hi John,
 
> Aunt Martha isn't running Arch. If she isn't on M$Win, she's probably on Fedora 16 or Suse 11.
 
Really? Distrowatch has Mint at #1, Ubuntu #2, Fedora #3.
 
I tried Mint myself, and found that I can build Gramps on that exactly like I build it on Xubuntu now. And I read that many users chose Mint, because they didn’t like the Unity desktop.
 
cheers,
 
Enno
 

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Jeremy Bicha-2
In reply to this post by Benny Malengier
On 13 January 2013 16:56, Benny Malengier <[hidden email]> wrote:
> Next LTS should be python3 only, so they are certainly working on it:
> https://wiki.ubuntu.com/Python/3

Just to be clear about what that release goal means: The Ubuntu
developers would like to ship python3 instead of python 2.7 on the
install image (there are similar goals for gconf>gsettings and
GTK2>GTK3 although Firefox & LibreOffice are the big blockers there).
Python 2 will not be removed from the Debian or Ubuntu archives as
long as a significant number of packages that people use need it
(which means its removal is years away if it happens). Gramps is not
shipped on the Ubuntu DVD and depends on libraries that aren't on the
DVD so the release goal doesn't affect Gramps at all.

Arch was a bit too aggressive in redefining /usr/bin/python to point
to python3 but it's not too difficult for the Arch developers to
maintain a patch to force python2 if a package isn't ready for python3
yet.

Jeremy

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Josip-3
In reply to this post by Benny Malengier
On 12.01.2013 16:34, Benny Malengier wrote:
> For an actual 4.0.0 release we still need some things.
>
> 1/what to do with 'pyexiv2 module not loaded' in python3? Nick, what do
> you advice?

Autor advice from:
http://tilloy.net/dev/pyexiv2/

Deprecation warning
pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
around libexiv2. Thanks to GObject Introspection support, GExiv2
supports Python 2 and 3.
If your application uses pyexiv2, you might want to consider porting it
over to GExiv2.


--
Josip

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

John Ralls-2

On Feb 3, 2013, at 7:09 PM, Josip <[hidden email]> wrote:

> On 12.01.2013 16:34, Benny Malengier wrote:
>> For an actual 4.0.0 release we still need some things.
>>
>> 1/what to do with 'pyexiv2 module not loaded' in python3? Nick, what do
>> you advice?
>
> Autor advice from:
> http://tilloy.net/dev/pyexiv2/
>
> Deprecation warning
> pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
> around libexiv2. Thanks to GObject Introspection support, GExiv2
> supports Python 2 and 3.
> If your application uses pyexiv2, you might want to consider porting it
> over to GExiv2.

Yay!

Who has time to fix up the Gramps modules?

Regards,
John Ralls


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Benny Malengier


2013/2/4 John Ralls <[hidden email]>

On Feb 3, 2013, at 7:09 PM, Josip <[hidden email]> wrote:

> On 12.01.2013 16:34, Benny Malengier wrote:
>> For an actual 4.0.0 release we still need some things.
>>
>> 1/what to do with 'pyexiv2 module not loaded' in python3? Nick, what do
>> you advice?
>
> Autor advice from:
> http://tilloy.net/dev/pyexiv2/
>
> Deprecation warning
> pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
> around libexiv2. Thanks to GObject Introspection support, GExiv2
> supports Python 2 and 3.
> If your application uses pyexiv2, you might want to consider porting it
> over to GExiv2.

Yay!

Who has time to fix up the Gramps modules?

Regards,
John Ralls


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Tim Lyons
Administrator
In reply to this post by Josip-3
Josip-3 wrote
Deprecation warning
pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
around libexiv2. Thanks to GObject Introspection support, GExiv2
supports Python 2 and 3.
If your application uses pyexiv2, you might want to consider porting it
over to GExiv2.
I thought it was agreed here: http://gramps.1791082.n4.nabble.com/import-Image-pyExif-tp4657986p4657999.html
that the pyexiv dependent things would be moved to gramps-addons, so the warnings for its absence would no longer be present.

(Note PIL is used for cropping and resizing images so we need to keep it - I think PIL is independent of pyexif, but I could be wrong)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Nick Hall-6
I don't think we did agree to move the Image Metadata code into Gramps
addons.

In fact, I said that I would maintain it in Gramps core.  In addition, I
said that I was happy to extend the functionality further to better
integrate it with genealogical data.

I will change the existing code to use GExiv2.

Nick.


On 04/02/13 15:38, Tim Lyons wrote:

> Josip-3 wrote
>> Deprecation warning
>> pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
>> around libexiv2. Thanks to GObject Introspection support, GExiv2
>> supports Python 2 and 3.
>> If your application uses pyexiv2, you might want to consider porting it
>> over to GExiv2.
> I thought it was agreed here:
> http://gramps.1791082.n4.nabble.com/import-Image-pyExif-tp4657986p4657999.html
> that the pyexiv dependent things would be moved to gramps-addons, so the
> warnings for its absence would no longer be present.
>
> (Note PIL is used for cropping and resizing images so we need to keep it - I
> think PIL is independent of pyexif, but I could be wrong)
>
>
>
> --
> View this message in context: http://gramps.1791082.n4.nabble.com/What-blocks-us-for-4-0-tp4658077p4658557.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Nick Hall-6
Just to clarify things again, as I did in the previous thread -

There are two Image Metadata gramplets:

1. Metadata Viewer
2. Edit Image Metadata

I helped Rob out with the viewer, and the main library code is used by
both gramplets.  I am happy to maintain it.

The editor was Rob's project.  I will upgrade it but am not really
interested in it.  There are other metadata editors available.

I am interested in future development providing a better integration
with genealogical data.  If you want to move the editor into
gramps-addons, then I would have no objections.

Nick.


On 04/02/13 16:22, Nick Hall wrote:

> I don't think we did agree to move the Image Metadata code into Gramps
> addons.
>
> In fact, I said that I would maintain it in Gramps core.  In addition, I
> said that I was happy to extend the functionality further to better
> integrate it with genealogical data.
>
> I will change the existing code to use GExiv2.
>
> Nick.
>
>
> On 04/02/13 15:38, Tim Lyons wrote:
>> Josip-3 wrote
>>> Deprecation warning
>>> pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
>>> around libexiv2. Thanks to GObject Introspection support, GExiv2
>>> supports Python 2 and 3.
>>> If your application uses pyexiv2, you might want to consider porting it
>>> over to GExiv2.
>> I thought it was agreed here:
>> http://gramps.1791082.n4.nabble.com/import-Image-pyExif-tp4657986p4657999.html
>> that the pyexiv dependent things would be moved to gramps-addons, so the
>> warnings for its absence would no longer be present.
>>
>> (Note PIL is used for cropping and resizing images so we need to keep it - I
>> think PIL is independent of pyexif, but I could be wrong)
>>
>>
>>
>> --
>> View this message in context: http://gramps.1791082.n4.nabble.com/What-blocks-us-for-4-0-tp4658077p4658557.html
>> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What blocks us for 4.0

Benny Malengier



2013/2/4 Nick Hall <[hidden email]>
Just to clarify things again, as I did in the previous thread -

There are two Image Metadata gramplets:

1. Metadata Viewer
2. Edit Image Metadata

I helped Rob out with the viewer, and the main library code is used by
both gramplets.  I am happy to maintain it.

The editor was Rob's project.  I will upgrade it but am not really
interested in it.  There are other metadata editors available.

I am interested in future development providing a better integration
with genealogical data.  If you want to move the editor into
gramps-addons, then I would have no objections.

The main reason was we could not use it in python3. Now that we can, if there are no specific issues with the editor, we can leave it in as far as I'm concerned. If it slowly stops working in Gramps, it will be the same in gramps-addons anyway.

Benny

Nick.


On 04/02/13 16:22, Nick Hall wrote:
> I don't think we did agree to move the Image Metadata code into Gramps
> addons.
>
> In fact, I said that I would maintain it in Gramps core.  In addition, I
> said that I was happy to extend the functionality further to better
> integrate it with genealogical data.
>
> I will change the existing code to use GExiv2.
>
> Nick.
>
>
> On 04/02/13 15:38, Tim Lyons wrote:
>> Josip-3 wrote
>>> Deprecation warning
>>> pyexiv2 is now deprecated in favour of GExiv2, a GObject-based wrapper
>>> around libexiv2. Thanks to GObject Introspection support, GExiv2
>>> supports Python 2 and 3.
>>> If your application uses pyexiv2, you might want to consider porting it
>>> over to GExiv2.
>> I thought it was agreed here:
>> http://gramps.1791082.n4.nabble.com/import-Image-pyExif-tp4657986p4657999.html
>> that the pyexiv dependent things would be moved to gramps-addons, so the
>> warnings for its absence would no longer be present.
>>
>> (Note PIL is used for cropping and resizing images so we need to keep it - I
>> think PIL is independent of pyexif, but I could be wrong)
>>
>>
>>
>> --
>> View this message in context: http://gramps.1791082.n4.nabble.com/What-blocks-us-for-4-0-tp4658077p4658557.html
>> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12
Loading...