Remove global imports in modules

[dlpzx]

Feature or Bugfix

• Bugfix

Detail

The loader class that loads modules dependending on the module interface loads all module init files and then uses the interfaces to load specific parts of the module or to register/perform other operations. The issue is that in some modules we are importing some parts of the package at the top level of the __init__ file, which means that no matter what the module interface is, those imports will be executed.

Let's see it with an example. I am loading modules using the CDK_CLI_EXTENSION module in the cdk_cli_wrapper. The loader loads all init files of the modules in the config.json, and then uses the interface to load the pipelines module only. The issue is that in the init files of the modules it has also imported things like the DashboardRepository or SagemakerStudioEnvironmentResource for example. Pieces of code that are not needed in the CDK_CLI_EXTENSION.

This would be a minor issue, some extra pieces of code are loaded, okey. The bigger problem comes from "child-modules". The loader after loading everything checks if what is has been loaded has its correct interface or if it is a config.json module. Modules such as feed that are not directly specified in the config.json could be imported indirectly through some of this top-level imports in the init files and result in failure of the loading.

We have 2 options:

1. Make our loader aware of the source of each file it imports
2. Be strict with how we import in the init files

In this PR I went for 2 because our loader is complex enough and is already name-sensitive. I think adding more logic would make it very difficult to handle and it might have unexpected results.

Relates

• Generic dataset module and specific s3_datasets module - part 2 (Create datasets_base and move enums) #1257 - in this PR we realized about the issue

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[dlpzx]

Testing locally:

• modules load as normal when everything in config.json is enabled
• creation of organization, environment
• dataset, dataset indexed in catalog
• creation of play tools mlstudio, worksheet work as expected