Skip to content

Conversation

@Avasam
Copy link
Contributor

@Avasam Avasam commented Mar 8, 2024

Summary of changes

Moved declarations of @_call_aside defined globals closer to where they're defined. And after ResourceManager & WorkingSet to avoid forward reference issues
Extracted from #4242 Works towards #2345 , resolves a few reportOptionalCall issues that #4192 would raise

Pull Request Checklist

  • Changes have tests (existing runtime tests should pass, unblocks more type-checking PRs)
  • News fragment added in newsfragments/.
    (See documentation for details)
Comment on lines +3314 to +3331
if TYPE_CHECKING:
# All of these are set by the @_call_aside methods above
__resource_manager = ResourceManager() # Won't exist at runtime
resource_exists = __resource_manager.resource_exists
resource_isdir = __resource_manager.resource_isdir
resource_filename = __resource_manager.resource_filename
resource_stream = __resource_manager.resource_stream
resource_string = __resource_manager.resource_string
resource_listdir = __resource_manager.resource_listdir
set_extraction_path = __resource_manager.set_extraction_path
cleanup_resources = __resource_manager.cleanup_resources

working_set = WorkingSet()
require = working_set.require
iter_entry_points = working_set.iter_entry_points
add_activation_listener = working_set.subscribe
run_script = working_set.run_script
run_main = run_script
Copy link
Contributor

@abravalheri abravalheri May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My question here is:

Instead of "re-declaring" the global variables, wouldn't it make more sense to ditch the @_call_aside and just run the majority of the body of _initialize* functions directly on the global scope?

@jaraco, do you know if _call_aside()/_initialize_master_working_set()/_initialize() are used in pkg_resources just for the sake of organising the code, or is this very small delay on the execution a trick that solves a specific problem?

(I do like the way the code is organised right now, but if changes are needed for type-checking, I would prefer not having double book keeping. Of course we can decide that the type-checking here is not worth the trouble).

Copy link
Contributor Author

@Avasam Avasam May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer not having double book keeping

FWIW, you already have to for other checkers (just as a note, most of these variables were moved from the top of the file, so this PR doesn't introduce double book-keeping).

That being said, I agree it'd be nicer if we didn't have to, but I wouldn't want to revamp pkg_resources too much outside of making it a fully typed package to take it out of typeshed. Unless it's a simple change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a quick search, and it seems that there might be packages out there depending on pkg_resources._initialize*:

So we probably cannot avoid the double book keeping...

Copy link
Contributor

@abravalheri abravalheri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much @Avasam.

I think it is probably better to get this one going, we can address concerns in future PRs.

If we want the code to be "type-safe" at some point, we will probably need some degree typing gymnastics.

@abravalheri abravalheri merged commit 544b332 into pypa:main May 13, 2024
@Avasam Avasam deleted the pkg_resources-type-global-variables branch May 13, 2024 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants