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 customenv
- #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 loaderschema
instead of namespace - #2284 Add new loader extra
dialect
and use it as default dbttarget
and Meltano UI SQL dialect instead of namespace - #2283 Add new loader extra
target_schema
and use it as default dbtsource_schema
instead of loaderschema
- #2285 Add new transform extra
package_name
and use it in dbt’sdbt_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 customenv
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