py-scipy @0.13.3: enable py34 subport, python34 @3.4.0rc1:

[petrrr]

This port is quite relevant also as dependency. At least it is a dependency for a port I maintain. So it would be desirable to have Python 3.4 support enabled soon.

However, there might be an issue with this:

​http://comments.gmane.org/gmane.comp.python.scientific.devel/18467

Note: I am a bit confused with the date of this, which seems not to correspond with rc 1 release, so the issue might in reality refer to "beta" instead of "release candidate". Here the release schedule:

​http://www.python.org/dev/peps/pep-0429/

In case the above issue applies, I guess there are two options:

• wait for Python 3.4 rc 2 (upstream fix);
• apply the patch proposed above;

The maintainer of python34 might want to consider applying the cited patch before Python 3.4 rc2 is available, so I CC as well.

[petrrr]

This is a duplicate (double submission due to a trac issue) of #42467. Please close!

[michaelld (Michael Dickens)]

Does anyone have a diff on what MacPorts provides regarding py-scipy (still currently 0.13.3) support for python34 (now at rc2)? I don't have time right now to work out the details; hopefully someone else does have some time. If this were as simple as adding "34" support to the py-scipy list, that would be great ... but, I'm doubting this is the case.

[petrrr]

I understand that the above documented possible issue should not apply any more. Anyway, if nobody is faster, I might try to see what happens if py34 is enabled.

[michaelld (Michael Dickens)]

Go for it! Let this ticket know & if it works for you then I'll push the change.

[petrrr]

I now was able to do some testing regarding py34 subport. The port builds fine.

But there seems to be some problem with opportunistic linking. When I first build I had atlas installed, subsequent testing caused a segmentation fault. Building with atlas deactivated, avoids this problem. I imagine, this problem could affect the other subports as well. I have not tested this yet.

Some of the tests actually fail, but I think this is a know issued as the testing framework seems to have some flaws.

So I would propose to enable 'py34' subport here and track the opportunistic linking issue in a separate ticket.

[michaelld (Michael Dickens)]

I enabled Python 3.4 support in r117983. It seems to work for the most part for me, e.g.,

python3.4 -c "import scipy; scipy.test()"

returns

Ran 2027 tests in 22.574s
FAILED (KNOWNFAIL=2, SKIP=15, errors=13)

The same for Python 3.3 returns:

Ran 8775 tests in 113.905s
OK (KNOWNFAIL=113, SKIP=210)

which is obviously better. The same for Python 2.7 bombs out after just a few 100 tests, which is worse than for 3.4!

So, yeah; if there are opportunistic linking issue then open a new ticket with those.

[petrrr]

Replying to michaelld@…:

I enabled Python 3.4 support in r117983. It seems to work for the most part for me, e.g.,

python3.4 -c "import scipy; scipy.test()"

returns

Ran 2027 tests in 22.574s
FAILED (KNOWNFAIL=2, SKIP=15, errors=13)

The same for Python 3.3 returns:

Ran 8775 tests in 113.905s
OK (KNOWNFAIL=113, SKIP=210)

which is obviously better. The same for Python 2.7 bombs out after just a few 100 tests, which is worse than for 3.4!

Python 3.3 vs 3.4 looks very similar to what I was observing. I do not recall any problems with 2.7, but I can re-run the test again. However, when testing 3.4 for the first time I got a segmentation fault on testing due to opportunistic linking. Maybe you want to check for this as well.

So, yeah; if there are opportunistic linking issue then open a new ticket with those.

Yes, this is what I was planning. I just have not found the time to do more exhaustive testing on this, e.g. testing also for py33 and py27.