Now Available: Meltano v1.49.0

Today, we are excited to release Meltano version 1.49.0, which (among other things) standardizes on <PLUGIN_NAME>_<SETTING_NAME> for configuration environment variable names (e.g. TARGET_POSTGRES_HOST for target-postgres‘s host setting instead of PG_ADDRESS), makes environment variable expansion in setting values more flexible, and uses this to let you easily override your extractor’s load_schema.

Excited to try it out?

To upgrade Meltano and your Meltano project to the latest version, navigate to your project directory, activate the appropriate virtual environment, and run meltano upgrade. This will upgrade the meltano package and apply any necessary changes to your project.

What else is new?

The list below (copied from the changelog) covers all of the changes made to Meltano since the release of v1.48.0 on September 7:

New

• #2279 Populate primary setting env var and aliases when invoking plugin or expanding env vars
• #2349 Allow plugin setting (default) values to reference pipeline plugin extras using generic env vars, e.g. MELTANO_EXTRACT__<EXTRA>
• #2281 Allow plugin extra (default) values to reference plugin name, namespace, profile using generic env vars, e.g. MELTANO_EXTRACTOR_NAMESPACE
• #2280 Allow plugin extra (default) values to reference plugin settings using env vars, e.g. target_schema: $PG_SCHEMA
• #2278 Read setting values from <PLUGIN_NAME>_<SETTING_NAME> env vars, taking precedence over <PLUGIN_NAMESPACE>_<SETTING_NAME> but not custom env
• #2350 Add MELTANO_TRANSFORM_* transform pipeline env vars for transformer (configuration) to access
• #2282 Add new extractor extra load_schema and use it as default loader schema instead of namespace
• #2284 Add new loader extra dialect and use it as default dbt target and Meltano UI SQL dialect instead of namespace
• #2283 Add new loader extra target_schema and use it as default dbt source_schema instead of loader schema
• #2285 Add new transform extra package_name and use it in dbt’s dbt_project.yml and --models argument instead of namespace

Changes

• #2279 Fall back on setting values from <PLUGIN_NAME>_<SETTING_NAME> and <PLUGIN_NAMESPACE>_<SETTING_NAME> env vars if a custom env is defined but not used
• #2278 Stop unnecessarily prepopulating env on a newly added custom plugin’s settings definitions
• #2208 Standardize on setting env vars prefixed with plugin name, not namespace or custom env