numpy: update to github portgroup and add python33

[seanfarley (Sean Farley)]

There are two patches here: one that updates to the github portgroup and another that adds the beta version of 1.7.0 so that python33 can be supported. Perhaps, though, the entire port should update to 1.7.0b2 since that's pretty stable now?

[seanfarley (Sean Farley)]

py-numpy: use github portgroup

[seanfarley (Sean Farley)]

py-numpy: add python33 support

[mf2k (Frank Schima)]

In the future, please Cc the port maintainer(s).

[seanfarley (Sean Farley)]

Replying to macsforever2000@…:

In the future, please Cc the port maintainer(s).

Oops, I totally meant to do that but was posting too fast from a coffee shop. Sorry again >_<

[skymoo (Adam Mercer)]

Thanks for the patches, I like the idea of moving over to the github portgroup as that should simplify things. I'll get this pushed.

However I'm less certain about the second patch. The reason is that I don't really like the idea of ports installing beta versions, unless that's the idea of the port (i.e. a py-numpy-devel). There is also the issue of the current version comparison doesn't recognise beta or release candidate versions. So 1.7.0b2 is considered newer than 1.7.0, so when 1.7.0 is released the port will need to have it's epoch bumped so this is recognised as an upgrade.

[mf2k (Frank Schima)]

@ram: Agreed. Please keep to stable release versions. -devel versions of ports are for beta versions.

[seanfarley (Sean Farley)]

Replying to ram@…:

Thanks for the patches, I like the idea of moving over to the github portgroup as that should simplify things. I'll get this pushed.

Cool; thanks!

However I'm less certain about the second patch. The reason is that I don't really like the idea of ports installing beta versions, unless that's the idea of the port (i.e. a py-numpy-devel).

Yeah, I am on the fence about that as well. Though, numpy seems to take it's sweet time with release cycles.

There is also the issue of the current version comparison doesn't recognise beta or release candidate versions. So 1.7.0b2 is considered newer than 1.7.0, so when 1.7.0 is released the port will need to have it's epoch bumped so this is recognised as an upgrade.

Also, agreed. That's a really annoying fact about the version compare in macports. I might submit a patch that would alleviate some of these problems but haven't gotten around to making it robust enough.

[seanfarley (Sean Farley)]

Replying to macsforever2000@…:

@ram: Agreed. Please keep to stable release versions. -devel versions of ports are for beta versions.

Yeah, I don't know why I tried to update to a beta version instead of just patch numpy 1.6.2 to work with python33. I'll attach a revised patch for 2.patch (and rename it something more meaningful).

[skymoo (Adam Mercer)]

I've pushed 1.patch in r100276 with a couple of modifications:

1. Changed the livecheck to use github, as development is hosted here it seems to make sense instead of the scipy.org page
2. As the checksums have changed I've treated this like a stealth update to ensure that everyone is using the same source.

[seanfarley (Sean Farley)]

Replying to ram@…:

I've pushed 1.patch in r100276 with a couple of modifications:

1. Changed the livecheck to use github, as development is hosted here it seems to make sense instead of the scipy.org page

Thanks! Good catch with the livecheck.

2. As the checksums have changed I've treated this like a stealth update to ensure that everyone is using the same source.

Ah, right, I was a little sloppy there.

[seanfarley (Sean Farley)]

Replying to sean.michael.farley@…:

Replying to ram@…:

I've pushed 1.patch in r100276 with a couple of modifications:

1. Changed the livecheck to use github, as development is hosted here it seems to make sense instead of the scipy.org page

Thanks! Good catch with the livecheck.

Actually, isn't the livecheck already handled by the github port group? So, the only thing to set is "livecheck.type none" when it's a subport, right?

[skymoo (Adam Mercer)]

Replying to sean.michael.farley@…:

Actually, isn't the livecheck already handled by the github port group? So, the only thing to set is "livecheck.type none" when it's a subport, right?

Yes but it picks up the beta versions as well, and I only wanted to be alerted to stable versions.

[skymoo (Adam Mercer)]

Where did the patch-python33.diff and patch-python33-mtrand.diff patch files come from? Is there some upstream reference for these?

[seanfarley (Sean Farley)]

Replying to ram@…:

Replying to sean.michael.farley@…:

Actually, isn't the livecheck already handled by the github port group? So, the only thing to set is "livecheck.type none" when it's a subport, right?

Yes but it picks up the beta versions as well, and I only wanted to be alerted to stable versions.

Righto, good point. Should the github port group be changed too?

[skymoo (Adam Mercer)]

Replying to sean.michael.farley@…:

Righto, good point. Should the github port group be changed too?

Ideally but every project seems to use a different convention to indicate beta versions, sometimes the same project uses multiple ways.

[skymoo (Adam Mercer)]

Getting several testsuite failures, did you get these?

[seanfarley (Sean Farley)]

Replying to ram@…:

Getting several testsuite failures, did you get these?

It seems I pushed that patch too early. Looking at the failing output now.

[cooljeanius (Eric Gallager)]

Adding py33 support for numpy should mean that py33-pandas can come back now, right? iirc it depended on py33-numpy which hadn't been added yet, which was why it was removed...

[seanfarley (Sean Farley)]

py-numpy: add python33 support

[seanfarley (Sean Farley)]

Replying to ram@…:

Where did the patch-python33.diff and patch-python33-mtrand.diff patch files come from? Is there some upstream reference for these?

I basically followed these two threads:

​http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063483.html

​http://mail.scipy.org/pipermail/numpy-discussion/2012-August/063714.html

and grafted the four patches mentioned in those threads. Now, numpy.test() runs successfully for me. Can you give it another try with the newly uploaded patch?

[skymoo (Adam Mercer)]

Replying to sean.michael.farley@…:

Now, numpy.test() runs successfully for me. Can you give it another try with the newly uploaded patch?

Same here:

OK (KNOWNFAIL=7, SKIP=5)
<nose.result.TextTestResult run=3173 errors=0 failures=0>

I'll get this pushed.

[skymoo (Adam Mercer)]

r100283

[seanfarley (Sean Farley)]

Replying to ram@…:

r100283

Thanks!

[skymoo (Adam Mercer)]

Josh raised an interesting point on macports-dev (​http://lists.macosforge.org/pipermail/macports-dev/2012-December/021179.html):

A 752 kB patch? That's kind of big to be including in the ports tree. Isn't what it's patching generated code anyway?

Is there a way to patch what generates the generated code instead of the generated code itself?

[seanfarley (Sean Farley)]

Replying to ram@…:

Josh raised an interesting point on macports-dev (​http://lists.macosforge.org/pipermail/macports-dev/2012-December/021179.html):

A 752 kB patch? That's kind of big to be including in the ports tree. Isn't what it's patching generated code anyway?

Yep, I saw and responded:

​http://lists.macosforge.org/pipermail/macports-dev/2012-December/021180.html

Is there a way to patch what generates the generated code instead of the generated code itself?

The file is generated by cython which would end it being another dependency. I don't like when generated code is committed into a repo but, then again, it's one less dependency :-/

[skymoo (Adam Mercer)]

Thanks, I saw after reopening the ticket.

I'm not keen on adding another dependency especially as that dependency is a larger download than the patch, so lets leave it as it is and hope they don't take too long with 1.7.0