Opened 8 years ago

Closed 8 years ago

#37223 closed enhancement (fixed)

numpy: update to github portgroup and add python33

Reported by: seanfarley (Sean Farley) Owned by: skymoo (Adam Mercer)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: dh@…
Port: py-numpy

Description

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?

Attachments (4)

1.patch (1.6 KB) - added by seanfarley (Sean Farley) 8 years ago.
py-numpy: use github portgroup
2.patch (2.0 KB) - added by seanfarley (Sean Farley) 8 years ago.
py-numpy: add python33 support
test_output.txt (17.6 KB) - added by skymoo (Adam Mercer) 8 years ago.
37223-2-py-numpy.patch (773.8 KB) - added by seanfarley (Sean Farley) 8 years ago.
py-numpy: add python33 support

Download all attachments as: .zip

Change History (28)

Changed 8 years ago by seanfarley (Sean Farley)

Attachment: 1.patch added

py-numpy: use github portgroup

Changed 8 years ago by seanfarley (Sean Farley)

Attachment: 2.patch added

py-numpy: add python33 support

comment:1 Changed 8 years ago by mf2k (Frank Schima)

Cc: dh@… added
Owner: changed from macports-tickets@… to ram@…
Type: updateenhancement
Version: 2.1.2

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

comment:2 in reply to:  1 Changed 8 years ago by 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 >_<

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by mf2k (Frank Schima)

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

comment:5 in reply to:  3 Changed 8 years ago by 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.

comment:6 in reply to:  4 Changed 8 years ago by 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).

comment:7 Changed 8 years ago by 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.

comment:8 in reply to:  7 ; Changed 8 years ago by 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.

  1. 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.

comment:9 in reply to:  8 ; Changed 8 years ago by 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?

comment:10 in reply to:  9 ; Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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?

comment:12 in reply to:  10 ; Changed 8 years ago by 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?

comment:13 in reply to:  12 Changed 8 years ago by 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.

Changed 8 years ago by skymoo (Adam Mercer)

Attachment: test_output.txt added

comment:14 Changed 8 years ago by skymoo (Adam Mercer)

Getting several testsuite failures, did you get these?

comment:15 in reply to:  14 Changed 8 years ago by 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.

comment:16 Changed 8 years ago by 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...

Last edited 8 years ago by cooljeanius (Eric Gallager) (previous) (diff)

Changed 8 years ago by seanfarley (Sean Farley)

Attachment: 37223-2-py-numpy.patch added

py-numpy: add python33 support

comment:17 in reply to:  11 ; Changed 8 years ago by 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?

comment:18 in reply to:  17 Changed 8 years ago by 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.

comment:19 Changed 8 years ago by skymoo (Adam Mercer)

Resolution: fixed
Status: newclosed

comment:20 in reply to:  19 Changed 8 years ago by seanfarley (Sean Farley)

Replying to ram@…:

r100283

Thanks!

comment:21 Changed 8 years ago by skymoo (Adam Mercer)

Resolution: fixed
Status: closedreopened

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?

comment:22 in reply to:  21 Changed 8 years ago by 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 :-/

comment:23 Changed 8 years ago by 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

comment:24 Changed 8 years ago by skymoo (Adam Mercer)

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.