@Scout I am using

load_assets_from_package_module

to load some assets from a module, and assign them a auto materialized policy with the parameter auto_materialize_policy, the thing is that some of those assets(which I cant control) already have one defined, and this is making the code crash, is there a way Ic an solve it? Both ways, by overwritting the policy or respecting the assets that already have one

When using

load_assets_from_package_module

to load assets from a module, you can specify an

auto_materialize_policy

to apply to all the loaded assets. However, if some of the assets already have an auto materialization policy defined, this can lead to conflicts and cause the code to crash. The documentation does not explicitly state how to handle the scenario where some assets already have an auto materialization policy defined and you want to apply a different policy to the rest of the assets in the module. It also does not provide a direct solution for either overwriting the existing policy or respecting the assets that already have one. Given this situation, you might consider the following approaches, although they are not explicitly supported by the documentation: 1. Manually Load Assets: Instead of using

load_assets_from_package_module

, you could manually load each asset and apply the desired auto materialization policy to those that do not already have one. This would give you full control over which policy is applied to each asset. 2. Modify Asset Definitions: If you have control over the asset definitions, you could modify them to accept an optional auto materialization policy parameter that could be set when loading the assets. This way, the policy could be specified or overridden at the time of loading. 3. Check for Existing Policies: If the assets provide a way to check whether an auto materialization policy is already set, you could potentially write a wrapper or utility function that loads the assets and only applies the new policy to those without an existing one. Since the documentation does not provide a clear answer, these suggestions are speculative and would need to be tested in your specific context. If these approaches do not work or are not feasible, you may need to seek further assistance from the Dagster community or maintainers, such as by creating a GitHub issue or asking for help in the Dagster Slack channel.