Re: GSoC project request for comments
+1 for optional dependency, but only if optional. My motivation: - possibly better underlying graph library than using our own quick implementation (though, I am not too familiar with networkx) - much faster progress in GSoC project Johannes Schönberger On Jun 11, 2014, at 11:22 AM, Ronnie Ghose <ronnie.ghose@gmail.com> wrote:
+1 as an optional module for additional functionality - I'm not a fan of monolithic libraries
On Jun 11, 2014 11:18 AM, "Juan Nunez-Iglesias" <jni.soma@gmail.com> wrote: Hi all,
We are trying to make a pretty big decision regarding the API for graph segmentation methods as part of Vighnesh's GSoC project. The main question is whether to implement our own graph class and build on that, or to use networkX. This would add a (potentially optional) dependency to skimage, but would use established classes an APIs.
Here's where the relevant discussion on the skimage-gsoc mailing list starts:
https://groups.google.com/d/msg/skimage-gsoc/sAhf0ecpHXM/io2LxCU8VC8J
As such a decision has a major impact on the skimage API going forward, please take some time to respond to this!
Thanks,
Juan.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I have no bias to either, though I do contribute to networkX and believe it would be faster than what we can do for some cases, also it has nice implementations for some things - so maybe format compatibility between the two would be nice On Wed, Jun 11, 2014 at 1:20 PM, Johannes Sch önberger <jsch@demuc.de> wrote:
+1 for optional dependency, but only if optional.
My motivation:
- possibly better underlying graph library than using our own quick implementation (though, I am not too familiar with networkx) - much faster progress in GSoC project
Johannes Sch önberger
On Jun 11, 2014, at 11:22 AM, Ronnie Ghose <ronnie.ghose@gmail.com> wrote:
+1 as an optional module for additional functionality - I'm not a fan of monolithic libraries
On Jun 11, 2014 11:18 AM, "Juan Nunez-Iglesias" <jni.soma@gmail.com> wrote: Hi all,
We are trying to make a pretty big decision regarding the API for graph segmentation methods as part of Vighnesh's GSoC project. The main question is whether to implement our own graph class and build on that, or to use networkX. This would add a (potentially optional) dependency to skimage, but would use established classes an APIs.
Here's where the relevant discussion on the skimage-gsoc mailing list starts:
https://groups.google.com/d/msg/skimage-gsoc/sAhf0ecpHXM/io2LxCU8VC8J
As such a decision has a major impact on the skimage API going forward, please take some time to respond to this!
Thanks,
Juan.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I’ll go on record saying +1 for including NetworkX as a *required* dependency. It’s a big decision, but here’s why: - NetworkX is pure Python, and if any target system satisfies our dependencies they should be able to build NetworkX with no problems - NetworkX is mature, so the prior statement should not change - While right now the use and utility of a robust graph representation in scikit-image would be somewhat limited, graph theory has strong utility throughout the package. The third point is the reason I favor a required dependency rather than an optional one. At present making it an optional dependency would not be that difficult, but if we make it *required* we can build on it without constant concern of fallback code paths or functions which just won’t exist if NetworkX is missing. Also, this would ensure our full package is exposed to the most users; e.g., Anaconda/Canopy/pip fetch and build required dependencies but not all have elegant provisions for optional ones. If NetworkX weren’t mature and/or if NetworkX didn’t share dependencies with scikit-image, my answer would be different.
@Josh what about say these features are only possible if you install blah like matplotlib + certain graphing capabilities. On Wed, Jun 11, 2014 at 7:22 PM, Josh Warner <silvertrumpet999@gmail.com> wrote:
I’ll go on record saying +1 for including NetworkX as a *required* dependency. It’s a big decision, but here’s why:
-
NetworkX is pure Python, and if any target system satisfies our dependencies they should be able to build NetworkX with no problems -
NetworkX is mature, so the prior statement should not change - While right now the use and utility of a robust graph representation in scikit-image would be somewhat limited, graph theory has strong utility throughout the package.
The third point is the reason I favor a required dependency rather than an optional one. At present making it an optional dependency would not be that difficult, but if we make it *required* we can build on it without constant concern of fallback code paths or functions which just won’t exist if NetworkX is missing. Also, this would ensure our full package is exposed to the most users; e.g., Anaconda/Canopy/pip fetch and build required dependencies but not all have elegant provisions for optional ones.
If NetworkX weren’t mature and/or if NetworkX didn’t share dependencies with scikit-image, my answer would be different.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
I think we should lay out the advantages that NetworkX will give us first. I like Juan's other idea of having a compatible interface for easily converting our graph structure to NetworkX format.
participants (4)
-
Johannes Schönberger -
Josh Warner -
Ronnie Ghose -
Stéfan van der Walt