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

VTK 8: minimal version? #1389

Closed
skoudoro opened this Issue Dec 8, 2017 · 7 comments

Comments

Projects
5 participants
@skoudoro
Copy link
Member

skoudoro commented Dec 8, 2017

VTK 8 seems to be available on Pypi like you can see here and available on conda-forge like you can see here.

Having these VTK packages on this 2 packages managers is a really good news for us !
I think we should start to define VTK 8 as a minimal version.

I would like to know what do you think @MarcCote @ranveeraggarwal @arokem @Garyfallidis @dmreagan ?

@jchoude

This comment has been minimized.

Copy link
Contributor

jchoude commented Dec 8, 2017

I think that before requiring it, we should ensure that the installation really works on a variety of OSes (Ubuntu 14.04, 16.04, the recent MacOSes, Windows).

If we make it a mandatory requirements without ensuring it's easy to deploy, I fear some users will encounter difficulties later on.

Also, I have not watched closely the visualization related PRs, but are there features from VTK 8 that would really simplify the framework / the developers' life?

@skoudoro skoudoro changed the title VTK 8: minimal requirement ? VTK 8: minimal version? Dec 8, 2017

@jchoude

This comment has been minimized.

Copy link
Contributor

jchoude commented Dec 8, 2017

Also, I know this has been discussed a few times, but I cannot find the PRs or issues related to that.

I feel like this brings back again the topic of "should the visu part be split from core dipy?". From the multiple people we help with pipelines in the lab and in collaborations, I get the feeling that, most of the time, people don't need (at first) all the visualization capabilities that are included in dipy.

I also encountered a few times problems with installing those dependencies, especially on headless clusters. Admittedly, this has been less frequent in the last months, with various improvements in packaging systems.

Wouldn't it make sense to split dipy.viz in a separate project, especially since this could be of interest for people from other background?

I'm really just curious to see how peoples' opinions have evolved. And sorry if this is a repetitive debate, this issue just made me think about all of that again.

Cheers!

@skoudoro

This comment has been minimized.

Copy link
Member

skoudoro commented Dec 8, 2017

Totally agree with you @jchoude (concerning tests). Sorry, I made a mistake in my title. I just corrected it.

The fewer the better concerning minimal requirement and I think VTK should stay optional.

Concerning dipy.viz , look at the end of discussion of #1296

@matthew-brett

This comment has been minimized.

Copy link
Member

matthew-brett commented Dec 8, 2017

For the VTK dependency, I humbly beg - please no. It's one of the worst requirements in the entire Python ecosystem. There are still no Mac wheels, even in the development version that's up on Pypi.

@ranveeraggarwal

This comment has been minimized.

Copy link
Member

ranveeraggarwal commented Dec 8, 2017

+1 to making the project separate. Apart from the obvious removal of dependency and making it accessible to other projects, making dipy.viz separate could also invite more contributors who have a background in visualization and not medical imaging.

As far as VTK 8 is concerned, we need to check if there are any breaking changes (given that it's a major version bump) and if it's stable. Previously, some viz elements had gotten completely messed up on VTK 7.0 (and later worked on VTK 7.1). We don't want something similar to happen.
Furthermore, a lot of people still use VTK 6.3/5.8 (which IIRC are pretty stable versions), so we need to be backward compatible.

@Garyfallidis

This comment has been minimized.

Copy link
Member

Garyfallidis commented Dec 8, 2017

If you see the previous discussion my plan for splitting the viz was for version 1.0. But perhaps we can speedup the process. Will now prioritize release 0.14 this January and putting up the new website. After this is done will write down a plan for the split and will share it with all interested members.

@jchoude

This comment has been minimized.

Copy link
Contributor

jchoude commented Dec 8, 2017

Yes, saw that. Cool, thanks!

@dmreagan dmreagan added this to Issues in Viz Module Jan 29, 2018

@skoudoro skoudoro closed this Sep 15, 2018

@skoudoro skoudoro moved this from Issues to Done in Viz Module Sep 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment