`_plot_2D_cube` fails after slicing 3D cube about ndcube HOT 13 CLOSED

Hi @byrdie. Thanks for raising this issue. I tried your minimal working example and it worked fine for me. Can I ask what version of ndcube you are using? You can test this by doing:

>>> import ndcube
>>> ndcube.__version__

where version is surrounded by two underscores on each side.

from ndcube.

@DanRyanIrish, that is interesting that it works for you, I wonder what I could've done to my system.

I should be running the latest version of ndcube from the master branch, however running the commands you suggest gives

>>> import ndcube
>>> ndcube.__version__
'1.0'

from ndcube.

Hi @byrdie. I thought that must have been the issue. Update ndcube to 1.0.1 and that'll fix your problem.

from ndcube.

I don't understand, I cloned and installed the master branch, how is that not the latest version? I can even see the commits I just merged in...

from ndcube.

Ah. So there are two different types of installs. Stable and bleeding edge. The stable versions are installed via pip or better still conda. The bleeding edge version can be installed but is a more manual process. Cloning the GitHub repo is not the same as installing the bleeding edge version, but is required before you can install the bleeding edge version. The fact that the version number of the module you imported is '1.0' shows you are importing the stable version of ndcube, albeit not the latest stable version. Assuming you installed ndcube via conda, you do

conda update ndcube

from a terminal. Then you can start python, import ndcube and check the version number is 1.0.1. If this is the case, the problem this issue raised should be fixed.

Now to the second question regarding the bleeding edge. The bleeding edge version is the master branch from the GitHub repo. The bleeding edge now includes your commits. The bleeding edge is not the same as the latest stable version. The latest stable version is a saved snapshot of the bleeding edge version from the past when we were confident that everything worked. (Although you have shown that for version 1.0 we missed some bugs, which is why we then released 1.0.1.) With a stable version saved and not changing in time, we are then free to keep adding features and bug fixes to the bleeding edge version without worrying about breaking the latest stable version that most people should be using.

It is possible to install the bleeding edge and use that in your coding. But BE WARNED! As the name suggests, the bleeding edge is not stable and may change at any time, possibly causing code you've written relying on it to break. The advantage however, it you can get the latest new features and bug fixes straight away without waiting for a new stable release. I would discourage people installing the bleeding edge version unless either:

• You want to contribute to the development of ndcube, in which case you will want to play with the latest features and test them.
• The latest features and bug fixes are essential to your research.

If either of the above apply to you, I am happy to explain how to install the the bleeding edge version.

from ndcube.

Sorry, I should've been more clear. Following the instructions here, I both cloned the repo and installed it using pip, which I thought should install the bleeding edge version. Here are the commands I used in Linux Mint 18:

mkdir ~/sunpy
cd ~/sunpy
git clone https://github.com/sunpy/ndcube.git ndcube_dev
cd ndcube_dev
pip3 install -e .

I checked that the version installed above is indeed the version being used using the following commands

>>> import ndcube
>>> ndcube.__version__
'1.0'
>>> ndcube.__file__
'/home/byrdie/sunpy/ndcube_dev/ndcube/__init__.py'

Since ndcube.__file__ points to the correct location, I assume pip installed it correctly, however it seems that the version is still wrong. Is the default branch on Github not the bleeding edge branch?

from ndcube.

Ah! Thank you for clarifying @byrdie. I think I know what the problem is then. But first, can you confirm what version of sunpy you are using?

from ndcube.

Sure, no problem

>>> import sunpy
>>> sunpy.__version__
'0.9.3'

from ndcube.

Yep. That's the problem. The bleeding edge version of ndcube relies on the bleeding edge version of sunpy. So will have to follow the instructions you linked above for installing the bleeding edge version of sunpy as well. That should fix it.

If you don't want to rely on the bleeding edge version of sunpy, I would recommend using ndcube 1.0.1. You won't have all the latest ndcube features but I don't think this specific issue will be a problem for you.

from ndcube.

So apparently I had the both the bleeding edge (installed using pip3 install -e .) and stable versions (installed using pip3 install sunpy) of sunpy installed, and I think they were colliding with each other a little bit. I removed the stable version using the commands

rm ~/.local/lib/python3.5/site-packages/sunpy.egg-link
pip uninstall sunpy

and made sure the bleeding edge version was up-to-date

cd ~/sunpy/sunpy_dev
git pull
pip3 install -e .

and checked that I was using the correct version

>>> import sunpy
>>> sunpy.__version__
'1.0.dev9964'
>>> sunpy.__file__
'/home/byrdie/sunpy/sunpy_dev/sunpy/__init__.py'

but I am still getting the same error running my code from above!
It may be that my python install is just irrecoverably damaged and I should just reinstall.

from ndcube.

Try uninstalling with conda? conda remove sunpy
Otherwise a fresh install might be the easiest fix.

from ndcube.

Hi @byrdie. Did you ever determine whether this issue was indeed fixed by rebuilding your conda install?

from ndcube.

Hi @byrdie. I'm going to close this issue. But if you are still experiencing this problem please let us know. FYI, we have just released a new verison of ndcube, 1.1.1. So updating to that version may also solve you problem. If you find new bugs with 1.1.1 please also let us know and we can try to address them.
Thanks!

from ndcube.