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

FIX: evaluate_connect_function should raise error on un-nested imports #3655

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

scott-huberty
Copy link

@scott-huberty scott-huberty commented Jun 17, 2024

Summary

if I'm understanding evaluate_connect_function correctly, the intent of the if-clause is to catch errors that arise from calling libraries/modules/functions that were imported at the module level (as opposed to nesting the imports at the function level), and raises a more informative error for those cases.

I think nipreps/nibabies#365 gives one example where the if-clause should catch such an error, but doesn't, because the error doesn't start with "global name". So I think it should be okay to make the if-clause more permissive, i.e. just check if the error message ends with "is not defined", then return the extra-informative error message to the user.

What do you think?

@scott-huberty scott-huberty changed the title FIX: evaluate_connect_function should catch untested imports FIX: evaluate_connect_function should raise error on un-nested imports Jun 17, 2024
@effigies
Copy link
Member

effigies commented Oct 6, 2024

I think this is probably a change in Python's error messages, which should not be relied upon as an API. We should probably just do:

    except NameError as e:
        e.args = (
            *e.args,
            "Due to engine constraints all imports have to be done inside each function definition"
        )
        raise e

Copy link

codecov bot commented Oct 6, 2024

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 70.85%. Comparing base (fffc1c2) to head (df241b2).

Files with missing lines Patch % Lines
nipype/pipeline/engine/utils.py 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff            @@
##           master    #3655     +/-   ##
=========================================
  Coverage   70.84%   70.85%             
=========================================
  Files        1277     1277             
  Lines       59118    59116      -2     
  Branches     9803     8596   -1207     
=========================================
+ Hits        41884    41887      +3     
- Misses      16067    16084     +17     
+ Partials     1167     1145     -22     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

scott-huberty added a commit to scott-huberty/nipype that referenced this pull request Oct 8, 2024
This incorporates Chris's suggestions from nipy#3655 (comment)

Except I raise a new error and include the original error message (instead of revising the original error message).

Co-authored-by: Chris Markiewicz <[email protected]>
@scott-huberty
Copy link
Author

I think this is probably a change in Python's error messages, which should not be relied upon as an API. We should probably just do:

    except NameError as e:
        e.args = (
            *e.args,
            "Due to engine constraints all imports have to be done inside each function definition"
        )
        raise e

Thanks @effigies , I think that is a nice idea (much simpler).

I incorporated this suggestion in 4e0b503 , except that I just explicitly raise a NameError, and via string formatting I include the original message plus our extra info (as opposed to overwriting the original error message). Since it looks like Nipype supports 3.7 or later I think this should be okay, but let me know if you disagree!

scott-huberty and others added 2 commits October 10, 2024 11:44
…ect_function more permissive

the if-statement in this function is very specific and ensures that the error message both starts with "global name" and ends with "is not defined" before raising the informative error about nested imports. nipreps/nibabies#365 gives one example where this if-statement is too specific, and doesn't catch a NameError that does actually arise from a module-level import.
This incorporates Chris's suggestions from nipy#3655 (comment)

Except I raise a new error and include the original error message (instead of revising the original error message).

Co-authored-by: Chris Markiewicz <[email protected]>
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.

2 participants