Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MRG: Release candidate 2.0.2 #377

Merged
merged 23 commits into from Nov 23, 2015
Merged

Conversation

effigies
Copy link
Member

@effigies effigies commented Nov 6, 2015

This is a cherry-picked branch off of maint/2.0.x of the bug-fix pull-requests since 2.0.1. The only PR that needed a little massaging was #363.

There are a number of little DOC and TST fixes that could probably also fit in, if people think it makes sense.

Closes #373

@@ -24,6 +24,23 @@ and Stephan Gerhard (SG).

References like "pr/298" refer to github pull request numbers.

* Upcoming

* Trackvis reader will now allow final streamline to have fewer points that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trackvis changes not included in fact.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you rather pull in the changes or drop the changelog entry?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just drop the changelog entry I guess, it is a minor API change.

Make TripWireError subclass AttributeError.  This prevents the Python
3.5 doctest machinery triggering a TripWireError when inspecting the
module containing a TripWire instance during doctest initialization.
The doctest string markup was for allowing doctests running on Python 3
and Python < 2.6.   We haven't used it for a few years.  This commit
removes that code in the hope that no-one else is using it.
@effigies
Copy link
Member Author

effigies commented Nov 6, 2015

Removed the changelog entries.

@yarikoptic @ignatenkobrain Any extra commits in Debian/Fedora packages that you'd like to see in this release?

@yarikoptic
Copy link
Member

On Fri, 06 Nov 2015, Chris Markiewicz wrote:

Removed the changelog entries.

[1]@yarikoptic [2]@ignatenkobrain Any extra commits in Debian/Fedora packages
that you'd like to see in this release?

I don't think I have any patches BUT I would appreciate if you give me
one day -- I will test 2.0.1-148-gdd4e725 regarding different
debian/ubuntu releases and possibly breaking dependents

Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik

@effigies
Copy link
Member Author

effigies commented Nov 6, 2015

Sounds good. I don't think we're in a rush, so just ping this thread when you're ready to go.

@ignatenkobrain
Copy link

I don't see new problems, but would be great if you will fix import for pydicom. Because we need to do import pydicom instead of import dicom.

@ignatenkobrain
Copy link

@effigies
Copy link
Member Author

effigies commented Nov 6, 2015

That means something like #351. I may have a few minutes to give that a try, but we'll need to test.

@matthew-brett Is it easy to make a new Travis test that would test against pydicom 1.0?

@yarikoptic
Copy link
Member

FWIW -- everything looked splendid across debians for me with 2.0.1-148-gdd4e725

@effigies
Copy link
Member Author

effigies commented Nov 6, 2015

@yarikoptic Not sure quite how to interpret the string 2.0.1-148-gdd4e725. I'm guessing that means applying this branch to your last debian release?

@yarikoptic
Copy link
Member

On Fri, 06 Nov 2015, Chris Markiewicz wrote:

[1]@yarikoptic Not sure quite how to interpret the string 2.0.1-148-gdd4e725.
I'm guessing that means applying this branch to your last debian release?

$> git show 2.0.1-148-gdd4e725 
commit dd4e725156206661aa218db9b3be9c2f02246ecf
Author: Matthew Brett <matthew.brett@gmail.com>
Date:   Thu Nov 5 18:24:45 2015 -0800

    DOC: remove trailing sentence

    Fixes gh-374.

that was the output of git describe on master at that point, e.g. as

$> git describe dd4e725156206661aa218db9b3be9c2f02246ecf
2.0.1-148-gdd4e725

@effigies
Copy link
Member Author

effigies commented Nov 7, 2015

Oh, I see. Just FYI this PR is just cherry-picked bug fixes on top of the maint/2.0.x branch, not everything that's gone into master.

If people would rather just package master into a new release, that's fine, too. These were almost clean cherry-picks, so I've sunk very little work into this branch.

@ignatenkobrain
Copy link

@effigies can you also backport pydicom's patch to this PR? It's required oneline massaging only.

@matthew-brett
Copy link
Member

Chris - any interest in being the release manager for this one? Instructions here : https://github.com/nipy/nibabel/blob/master/doc/source/devel/make_release.rst - but I am sure they could be improved.

TST: Use consistent import style in tests

Conflicts:
	nibabel/nicom/dicomwrappers.py

Backport retains BinOpener
@effigies
Copy link
Member Author

@bcipolli @surchs Would you mind testing this branch with the NIPY_EXTRA_TESTS=slow environment variable set, as well? I added a commit that's just #383 squashed and backported.

@bcipolli
Copy link
Contributor

Worked like a champ!

@effigies
Copy link
Member Author

Cool. Thanks for the validation.

@effigies effigies force-pushed the candidate2.0.2 branch 2 times, most recently from 56e3e9b to 587f4a1 Compare November 19, 2015 16:27
NB: This does not resolve the underlying issue (see
conda/conda#1824), but incidentally prevents
nibabel from triggering the bug during testing. -CJM
Squashed for 2.0.2 release.
See nipygh-383 for full history.

BF: Use buffered gzip read in Py3.5.0, specifically
TST: Add high-memory usage test for large nifti1 files

Conflicts:
	nibabel/testing/__init__.py
@effigies
Copy link
Member Author

Okay. I think code-wise, this is ready to go. @matthew-brett could you walk me through the build-bots? I'm not quite sure how to go about this. (Also ssh buildbot@nipy.bic.berkeley.edu echo doesn't work, so I don't think my key is in yet.)

And should I merge --ff into maint/2.0.x or use this PR? Any preference?

Edit: To clarify, I've done everything on the checklist up to python -m compileall ., except sdist and virtualenv tests, since they're on Travis.

@matthew-brett
Copy link
Member

Chris - I updated the instructions here : #386 - does that doc make sense to you?

@matthew-brett
Copy link
Member

For merging, my preference is always to do non-ff merge unless there's a good reason - to keep the set of commits as an identifiable set of work.

@effigies
Copy link
Member Author

Those instructions look good. I've been able to force builds (from the buildbot machine, not via the web interface), but haven't figured out pushing the NIPY_EXTRA_TESTS environment variable.

@matthew-brett
Copy link
Member

Did you manage to get the web interface working in the end? It's less useful as you have to push something to the main repo before you can build it - for example you can build a tag once it's pushed, but you usually want to try building stuff before it's pushed.

There's no easy way to push an environment variable, but in any case, the smaller Windows machine probably can't run the big test - the larger 64-bit machine probably can. I'll try enabling that by default on the larger Windows machine.

@matthew-brett
Copy link
Member

@matthew-brett
Copy link
Member

I had to do this by logging into the machine remotely and setting the enviroment variable in the users profile. Can give you access to this machine if you need it.

@matthew-brett
Copy link
Member

Oops - even for the 6GB windows machine it was too much:

http://nipy.bic.berkeley.edu/builders/nibabel-bdist64-27/builds/43/steps/shell_6/logs/stdio

======================================================================
ERROR: nibabel.tests.test_nifti1.test_large_nifti1
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslaves\mike-win7-64\nibabel-bdist64-27\build\venv\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "c:\Python27\lib\site-packages\numpy\testing\decorators.py", line 146, in skipper_func
    return f(*args, **kwargs)
  File "c:\buildslaves\mike-win7-64\nibabel-bdist64-27\build\venv\lib\site-packages\nibabel-2.1.0.dev0-py2.7-win-amd64.egg\nibabel\tests\test_nifti1.py", line 1257, in test_large_nifti1
    data = load('test.nii.gz').get_data()
  File "c:\buildslaves\mike-win7-64\nibabel-bdist64-27\build\venv\lib\site-packages\nibabel-2.1.0.dev0-py2.7-win-amd64.egg\nibabel\spatialimages.py", line 572, in get_data
    data = np.asanyarray(self._dataobj)
  File "c:\Python27\lib\site-packages\numpy\core\numeric.py", line 287, in asanyarray
    return array(a, dtype, copy=False, order=order, subok=True)
  File "c:\buildslaves\mike-win7-64\nibabel-bdist64-27\build\venv\lib\site-packages\nibabel-2.1.0.dev0-py2.7-win-amd64.egg\nibabel\arrayproxy.py", line 145, in __array__
    raw_data = self.get_unscaled()
  File "c:\buildslaves\mike-win7-64\nibabel-bdist64-27\build\venv\lib\site-packages\nibabel-2.1.0.dev0-py2.7-win-amd64.egg\nibabel\arrayproxy.py", line 140, in get_unscaled
    mmap=self._mmap)
  File "c:\buildslaves\mike-win7-64\nibabel-bdist64-27\build\venv\lib\site-packages\nibabel-2.1.0.dev0-py2.7-win-amd64.egg\nibabel\volumeutils.py", line 518, in array_from_file
    n_read = infile.readinto(data_bytes)
  File "c:\Python27\Lib\gzip.py", line 256, in read
    self._read(readsize)
  File "c:\Python27\Lib\gzip.py", line 308, in _read
    self._add_read_data( uncompress )
  File "c:\Python27\Lib\gzip.py", line 326, in _add_read_data
    self.extrabuf = self.extrabuf[offset:] + data
MemoryError

@effigies
Copy link
Member Author

Yeah. I can run the test on a 24GB machine but not an 8GB machine. Maybe if we just have one of the build slaves set to always run with NIPY_EXTRA_TESTS=slow,bigmem, and we make sure to run against that one before releases, that will be enough?

Also, I set up a pypi user cjmarkie, in case you need to add upload permissions.

@matthew-brett
Copy link
Member

OK - done for pypi.

I enabled slow,bigmem test for the big Mac buildslave:

nipy/nibotmi@2322a76

(I had to log on and update the relevant file on that machine, then restart the buildbot slave).

I updated the release instructions adding the suggestion to run on this machine first:

https://github.com/nipy/nibabel/pull/386/files#diff-d13ddc96596291d914cd84c6165cc10bR130

@effigies
Copy link
Member Author

Great. Build successful.

I think I should be good to go. I'll let you know if I run into any more issues.

effigies added a commit that referenced this pull request Nov 23, 2015
@effigies effigies merged commit 8522d9d into nipy:maint/2.0.x Nov 23, 2015
@effigies effigies deleted the candidate2.0.2 branch November 23, 2015 21:31
@effigies
Copy link
Member Author

@matthew-brett Release pushed. Hopefully I didn't somehow miss anything too egregious. Will make notes on #386.

@ignatenkobrain 2.0.2 is released. Source is also on pypi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants