-
Notifications
You must be signed in to change notification settings - Fork 533
Checking testing dependencies at runtime #2680
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
Comments
@TheChymera It looks like the nipypecli crash command failed - could you install FWIW, |
@djarecka @oesteban @effigies I'd rather discuss this here than in the PR thread, but would you be interested in making (or instructing me on how to best make) the testing dependencies non-mandatory? Or generally eviscerating explicit dependency testing? I don't think it's a good idea for things to fail unless they have to (makes the package less accessible), and as it stands a lot of non-testing functionalities fail just because some unrelated deps are not present. I read the aforelinked conversation and I think this
is a rather problematic rationale. I'd rather put it the other way around and say that we already have heaps of deps and many potential failure points because of them, the least we could do is keep the absence of the non-critical ones non-critical. |
@TheChymera - well, I agree that you can argue with my rationale, but my main point was that in IMO, it's nice that users can test the library, but if others prefer to skip it, we can remove it. I believe that |
we can also consider limiting ourselves to |
So specifically the Line 3 in 3dc5500
Unfortunately, there doesn't seem to be an easy way to use parallelism if But anyway, my impression of this issue is that |
@djarecka yes, that's what I would also suggest.
@effigies I think this is the actual issue here and it got conflated with some other issue regarding the way CI testing is performed. I'd be happy to help remove the explicit dependency check, but based on the text I am getting I can't figure out where exactly it gets generated. Can you help me out? |
@TheChymera - sorry, I mixed two issue, here indeed you shouldn't have the error when running your workflow. We should try to fix it. Regarding suggestion of removing testing dependencies completely: let's ask other developers( @satra , @oesteban , @chrisfilo) if they prefer to remove all testing dependencies. I'm still voting for leaving |
It looks like it's a function of how scripts are installed. Lines 151 to 154 in 3dc5500
I haven't the slightest idea how to keep it from checking everything that's in |
is this the case? I wasn't able to replicate it in an environment without |
This is specifically a It's unclear how this got installed without installing all of the dependencies. @TheChymera How did you actually install nipype? |
Closed by #2850. |
Summary
It appears
=nipype-1.1.1
is checking at least one testing dependency at runtime and crashing all of my nodes if it is not present.This really shouldn't be happening, especially not for a testing dep.
Shouldn't things just fail if+when the import statement fails?
I would like to
sed
the package for the 1.1.1 release to fix this behaviour, but I was unable to find the section of the code which does this.Actual behavior
Platform details:
Execution environment
The text was updated successfully, but these errors were encountered: