You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think our globals and locals need to be provided to the package being imported. So it's probably better to not pollute the package with our globals/locals!?
Also, it's a little scary to support importing any package by name as this is a huge potential security issue. But, maybe it's not a problem for us. Nonetheless, this is something that needs to be made very clear to the user, and potentially provide an allow/denylist approach.
I don't think our globals and locals need to be provided to the package being imported. So it's probably better to not pollute the package with our globals/locals!?
Also, it's a little scary to support importing any package by name as this is a huge potential security issue. But, maybe it's not a problem for us. Nonetheless, this is something that needs to be made very clear to the user, and potentially provide an allow/denylist approach.
Originally posted by @matham in #1 (comment)
The text was updated successfully, but these errors were encountered: