bug: Plugin config values might be unnecessarily expanded during plugin installation

Meltano Version
3.4.2 (and 3.5.0a4 for a new case)
Python Version
NA
Bug scope
CLI (options, error messages, logging, etc.)
Operating System
NA
Description
An annoying interaction between pipeline-specific environment variables like MELTANO_EXTRACT__LOAD_SCHEMA and the MELTANO_FF_STRICT_ENV_VAR_MODE feature flag occurs with meltano install and #8482.
Consider the following project:
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

This happens with the latest Meltano (v3.4.2 at the time of writing):
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano install
2024-07-12T00:24:23.462889Z [info     ] Installing 2 plugins
2024-07-12T00:24:23.471755Z [info     ] Installing extractor 'tap-smoke-test'
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.

Omitting MELTANO_FF_STRICT_ENV_VAR_MODE=true makes the installation succeed, so it's clear the variable MELTANO_EXTRACT__LOAD_SCHEMA is expected to have a value, although it's not required in any way to install any of the plugins.
A similar thing now happens in other commands with the introduction of #8482:
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano run tap-smoke-test target-duckdb
2024-07-12T00:29:58.442916Z [info     ] Environment 'dev' is active
2024-07-12T00:29:58.490541Z [info     ] Installing extractor 'tap-smoke-test'
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.

The latter can be problematic as it might break users' workflows, so we have a few options if we want to fix this.
Revert #8482
This is not ideal, since the functionality is useful indeed.
Make auto-install opt-in
This was actually the original suggestion in https://github.com/meltano/meltano/issues/2089:

Install operations are not always safe to run, and they can hide other issues in the invocation or installation [...]

This negates a big part of the benefit of the feature, but there'd still a the global toggle in the form of the auto_install Meltano setting to turn it on by default.
Avoid trying to expand values coming from a plugin's config dictionary
This was introduced by https://github.com/meltano/meltano/commit/148a73a69a033397091eace3a912cdd40c14c6f3 and occurs here
https://github.com/meltano/meltano/blob/eb10cdf7309051acb3b1e9c97f7d011a49a13367/src/meltano/core/plugin_install_service.py#L311
and more specifically here
https://github.com/meltano/meltano/blob/eb10cdf7309051acb3b1e9c97f7d011a49a13367/src/meltano/core/plugin_install_service.py#L474
where the plugin's config is expanded. This fails when it refers to a pipeline environment variable such as MELTANO_EXTRACT__LOAD_SCHEMA.
This does seem to fix the problem in both scenarios exemplified above, but Chesterton's Fence says that we should preserve this. On the other hand I can't think of a scenario where expanding a plugin's config values would be useful for installing the plugin.
Other workarounds and alternatives
There's of course the option of not using the strict_env_var_mode feature flag to shoot yourself in the foot 😅, but there may yet be other workarounds.
cc @WillDaSilva (as the author of 148a73a69a033397091eace3a912cdd40c14c6f3) @ReubenFrankel

Related:

https://github.com/meltano/meltano/issues/2089
https://github.com/meltano/meltano/issues/7548
https://github.com/meltano/meltano/pull/7019
https://github.com/meltano/meltano/pull/8482

Code
No response

This does seem to fix the problem in both scenarios exemplified above, but Chesterton's Fence says that we should preserve this. On the other hand I can't think of a scenario where expanding a plugin's config values would be useful for installing the plugin.

Yeah, it's a bit of a difficult one... Would it be possible to differentiate MELTANO_EXTRACT__LOAD_SCHEMA as a pipeline variable and ignore it during env var expansion during any command invocation that it would not normally be set under. Is that just el/elt?

Yeah, it's a bit of a difficult one... Would it be possible to differentiate MELTANO_EXTRACT__LOAD_SCHEMA as a pipeline variable programmatically and then ignore it during env var expansion for any command invocation that it would not normally be set under? Is that just anything other than el/elt?

I think ideally and I didn't mention this option above, we could do something similar to what meltano run or meltano el do under the hood and populate a shared environment with config from all the plugins in the context:
meltano run

https://github.com/meltano/meltano/blob/d8bd1b3cef3c59182f7b9c329753dd5af619d805/src/meltano/core/block/extract_load.py#L237-L260

meltano el

https://github.com/meltano/meltano/blob/d8bd1b3cef3c59182f7b9c329753dd5af619d805/src/meltano/core/elt_context.py#L466-L509

I think ideally and I didn't mention this option above, we could do something similar to what meltano run or meltano el do under the hood and populate a shared environment with config from all the plugins in the context:

Specifically for an install? How are you proposing that work for MELTANO_EXTRACT__LOAD_SCHEMA?

Specifically for an install?

Yeah, we'd pass all the merged env dictionary from all plugin contexts to each individual installation.

How are you proposing that work for MELTANO_EXTRACT__LOAD_SCHEMA?

I think the problem is that MELTANO_EXTRACT__LOAD_SCHEMA gets populated for the extractor, but it is required for the loader and not populated independently there. So in fact this works fine already:
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano invoke tap-smoke-test
024-07-12T17:16:13.787617Z [info     ] Environment 'dev' is active
2024-07-12T17:16:13.823082Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-12T17:16:25.220142Z [info     ] Installed extractor 'tap-smoke-test'
2024-07-12 11:16:28,863 | INFO     | root                 | animals stream max schema_inference_record_count hit
{"type":"STATE","value":{}}
2024-07-12 11:16:28,864 | INFO     | tap-smoke-test.animals | Beginning full_table sync of 'animals'...
2024-07-12 11:16:28,864 | INFO     | tap-smoke-test.animals | Tap has custom mapper. Using 1 provided map(s).
...

I'm finding this a bit hard to follow, but are there not two separate issue here:

Plugin contexts are not shared at install time
env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb

Working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

Not working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
      env:
        TEST: $MELTANO_EXTRACT__LOAD_SCHEMA
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:19:33.171147Z [info     ] Environment 'dev' is active
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.

MELTANO_EXTRACT__LOAD_SCHEMA is not available for certain commands (maybe others variables as well)
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

el/elt
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

run
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano run tap-smoke-test target-duckdb
2024-07-15T01:29:41.990516Z [info     ] Environment 'dev' is active
2024-07-15T01:29:42.133819Z [info     ] Installing extractor 'tap-smoke-test'
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.
...

This is not just an issue for run, but all commands that support auto-install other than el/elt. Not sure what the best solution is for this in particular, but

Avoid trying to expand values coming from a plugin's config dictionary

seems like it could work,

I'm finding this a bit hard to follow, but are there not two separate issues here:

Plugin contexts are not shared at install time:
env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb

Working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

Not working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
      env:
        TEST: $MELTANO_EXTRACT__LOAD_SCHEMA
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:19:33.171147Z [info     ] Environment 'dev' is active
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.

MELTANO_EXTRACT__LOAD_SCHEMA is not available for certain commands (maybe others variables as well)
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

el/elt
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

run
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano run tap-smoke-test target-duckdb
2024-07-15T01:29:41.990516Z [info     ] Environment 'dev' is active
2024-07-15T01:29:42.133819Z [info     ] Installing extractor 'tap-smoke-test'
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.
...

This is not just an issue for run, but all commands that support auto-install other than el/elt. Not sure what the best solution is for this in particular, but

Avoid trying to expand values coming from a plugin's config dictionary

seems like it could work,

I'm finding this a bit hard to follow, but are there not two separate issues here:

Plugin contexts are not shared at install time
env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb

Working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

Not working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
      env:
        TEST: $MELTANO_EXTRACT__LOAD_SCHEMA
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:19:33.171147Z [info     ] Environment 'dev' is active
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.

MELTANO_EXTRACT__LOAD_SCHEMA is not available for certain commands (maybe others variables as well)
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

el/elt
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

run
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano run tap-smoke-test target-duckdb
2024-07-15T01:29:41.990516Z [info     ] Environment 'dev' is active
2024-07-15T01:29:42.133819Z [info     ] Installing extractor 'tap-smoke-test'
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.
...

This is not just an issue for run, but all commands that support auto-install other than el/elt. Not sure what the best solution is for this in particular, but

Avoid trying to expand values coming from a plugin's config dictionary

seems like it could work,

I'm finding this a bit hard to follow, but are there not two separate issues here:

Plugin contexts are not shared at install time
env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb

Working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

Not working
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
      env:
        TEST: $MELTANO_EXTRACT__LOAD_SCHEMA
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:19:33.171147Z [info     ] Environment 'dev' is active
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.

MELTANO_EXTRACT__LOAD_SCHEMA is not available for certain commands (maybe other variables as well)
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
send_anonymous_usage_stats: false
plugins:
  extractors:
  - name: tap-smoke-test
    variant: meltano
    pip_url: git+https://github.com/meltano/tap-smoke-test.git
    config:
      streams:
      - stream_name: animals
        input_filename:
          https://raw.githubusercontent.com/meltano/tap-smoke-test/main/demo-data/animals-data.jsonl
    metadata:
      animals:
        key_properties: [id]
  loaders:
  - name: target-duckdb
    variant: jwills
    pip_url: target-duckdb~=0.6
    config:
      path: output/wh.duckdb
      default_target_schema: $MELTANO_EXTRACT__LOAD_SCHEMA

el/elt
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano el tap-smoke-test target-duckdb
2024-07-15T01:20:45.755049Z [info     ] Environment 'dev' is active
2024-07-15T01:20:45.969319Z [info     ] Installing extractor 'tap-smoke-test'
2024-07-15T01:20:46.010596Z [info     ] Installing loader 'target-duckdb'
...

run
$ env -i PATH="$PATH" HOME=$HOME MELTANO_FF_STRICT_ENV_VAR_MODE=true meltano run tap-smoke-test target-duckdb
2024-07-15T01:29:41.990516Z [info     ] Environment 'dev' is active
2024-07-15T01:29:42.133819Z [info     ] Installing extractor 'tap-smoke-test'
Environment variable 'MELTANO_EXTRACT__LOAD_SCHEMA' referenced but not set. Make sure the environment variable is set.
...

This is not just an issue for run, but all commands that support auto-install other than el/elt. Not sure what the best solution is for this in particular, but

Avoid trying to expand values coming from a plugin's config dictionary

seems like it could work,

2. > ### Avoid trying to expand values coming from a plugin's config dictionary
    seems like it could work.

Seems like the easiest option. Let's actually wait and see if someone complains 😅.
I don't think anyone complained about https://github.com/meltano/meltano/issues/7548 but me, so this might be the case again.

In the meantime, https://github.com/meltano/meltano/pull/8633 might help folks do something like:
# Only install the required plugins, don't run the pipeline
meltano run --only-install tap-hubspot target-postgres

# Don't install the already installed required plugins, only run the pipeline
meltano run --no-install tap-hubspot target-postgres


Using Docker as an alternative to Trellis for AWS deploying Bedrock sites

This is more of a query - How achievable is to use roots.io + Docker to achieve what is described in this project?
https://github.com/distributev/wordpress-laravel-docker-local-cloud
Any roots.io / Docker expert willing to take on this project?

Hi @distributev my company kilenda.de is built on Woocommerce (WP) and Dokku. As we prepare a major update, we are evaluating roots.io with very promising results. We have got a working project which integrates neatly into Gitlab CI, Docker and Dokku.
Thus I'd see your request as very achievable (as we are currently doing it). I would advise to split WordPress and Laravel into different projects, as they have very different structures with some infrastructure code in common.

don’t clear out the issue template... don’t use github for support.


Clarification in IoSkipCurrentIrpStackLocation documentation

In the documentation it states that if you use IoSkipCurrentIrpStackLocation but also set a completion routine afterwards you might overwrite a completion routine set by the driver below it. But I think it should be above.
IoSetCompletionRoutine sets the completion routine on the next stack location (IE IoGetNextIrpStackLocation, IE CurrentStackLocation - 1).
IoSkipCurrentIrpStackLocation just does
(Irp)->CurrentLocation++; \
(Irp)->Tail.Overlay.CurrentStackLocation++;

while IofCallDriver does
Irp->CurrentLocation--;
...
StackPtr = IoGetNextIrpStackLocation(Irp);
Irp->Tail.Overlay.CurrentStackLocation = StackPtr;
...

So if you do both you actually overwrite the completion set by the driver above and not below because the stack location stays the same. If the stack location is the same the completion routine there belongs to the driver above us (as IoSetCompletionRoutine sets the completion routine on the lower-level driver).

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ba0bfa34-1cee-7cc9-6233-35005388e5b5
Version Independent ID: ee0cbdfc-4258-bd30-2c65-0d5a66921c7a
Content: IoSkipCurrentIrpStackLocation - Windows drivers
Content Source: wdk-ddi-src/content/wdm/nf-wdm-ioskipcurrentirpstacklocation.md
Product: windows-hardware
Technology: wdk-api-reference
GitHub Login: @barrygolden
Microsoft Alias: bagold

Hi @ilay122 - you are correct!  Thank you for the report.  I've made the correction on https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-ioskipcurrentirpstacklocation.


bcal: 1.7 -> 1.8

Motivation for this change
Update which fixes the build on Darwin and should now work on AArch64 as well.
The tests failed for a good reason on Darwin and should not have been disabled in  #36581. The issue has been resolved upstream with version 1.8.
See also #36454 for ZHF.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @matthewbauer

@GrahamcOfBorg build bcal

Success on x86_64-darwin (full log)
Attempted: bcal
Partial log (click to expand)
gzip -c bcal.1 > bcal.1.gz
install -m 0644 bcal.1.gz /nix/store/x1swig4ap7yb0hc17y84rprhnkjvdbmm-bcal-1.8/share/man/man1
install -m 0644 README.md /nix/store/x1swig4ap7yb0hc17y84rprhnkjvdbmm-bcal-1.8/share/doc/bcal
rm -f bcal.1.gz
post-installation fixup
gzipping man pages under /nix/store/x1swig4ap7yb0hc17y84rprhnkjvdbmm-bcal-1.8/share/man/
strip is /nix/store/4sdh09gmvl15cy0zb6i7mbvxh5syz206-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/x1swig4ap7yb0hc17y84rprhnkjvdbmm-bcal-1.8/bin
patching script interpreter paths in /nix/store/x1swig4ap7yb0hc17y84rprhnkjvdbmm-bcal-1.8
/nix/store/x1swig4ap7yb0hc17y84rprhnkjvdbmm-bcal-1.8

Success on x86_64-linux (full log)
Attempted: bcal
Partial log (click to expand)
rm -f bcal.1.gz
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8
shrinking /nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8/bin/bcal
gzipping man pages under /nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8/bin
patching script interpreter paths in /nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8
checking for references to /tmp/nix-build-bcal-1.8.drv-0 in /nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8...
/nix/store/vs2fgv07m42zbzpj3hifk1h5f4sf5qrg-bcal-1.8

Success on aarch64-linux (full log)
Attempted: bcal
Partial log (click to expand)
rm -f bcal.1.gz
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8
shrinking /nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8/bin/bcal
gzipping man pages under /nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8/share/man/
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8/bin
patching script interpreter paths in /nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8
checking for references to /build in /nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8...
/nix/store/9lmyk1d5bfx2bs95888q797a26mqznxv-bcal-1.8


[GEODE-1923] Fix a test race condition.

for FixedPRSinglehopDUnitTest.test_FPAmetadataFetch
Using Awaitility allows us to make sure that the buckets have actually propagated, and should make the test take less time in general.

It looks like you also need to run "./gradlew spotlessApply" to reformat your changes.  The Travis build complained that spotlessJavaCheck failed.

I doubt that FixedPRSinglehopDUnitTest::primaryBucketsOnServer provides any benefit over FixedPRSinglehopDUnitTest.primaryBucketsOnServer()

@kohlmu-pivotal I just think it's a bit cleaner syntactically; there's no other real benefit.

@kohlmu-pivotal Could you merge this for me please?


Pod file issue in iOS App installation

Hi, my Xcode version is 11.0 and i'm trying to install LiveChat through pod file with name,
pod 'LiveChat', '~> 2.0.17' . Now when i install the file through terminal it shows me this error,
CocoaPods could not find compatible versions for pod "LiveChat": In Podfile: LiveChat (~> 2.0.17). How can i resolve this issue? What is the new pod file?

Hi @Hamza123Imran I'm not able to reproduce the issue on my side on Xcode 11 (official, installed from AppStore). What is the version of iOS you are targeting for?

I'm running my app on simulator and my minimum version is 10.0,
My xcode version is 11.0
This is pod file i'm trying to install. pod 'LiveChat', '~> 2.0.17' . @kamil-szostakowski

@Hamza123Imran could you please share your entire Podfile?

Podfile.zip
This is my pod file

@Hamza123Imran I tried with your podfile and everything was installed just fine. Do you use swift, if yes which version? Are you sure that you are not targeting tvOS or any other platform?
$ pod install
Analyzing dependencies
Downloading dependencies
Installing Alamofire (4.8.2)
Installing AppAuth (1.2.0)
Installing CardsLayout (0.0.1)
Installing CountryPickerView (3.0.3)
Installing FBSDKCoreKit (5.5.0)
Installing FBSDKLoginKit (5.5.0)
Installing FBSDKShareKit (5.5.0)
Installing FacebookCore (0.8.0)
Installing FacebookLogin (0.8.0)
Installing FacebookShare (0.8.0)
Installing GTMAppAuth (1.0.0)
Installing GTMSessionFetcher (1.2.2)
Installing GoogleMaps (3.1.0)
Installing GooglePlacePicker (3.1.0)
Installing GooglePlaces (3.1.0)
Installing GoogleSignIn (5.0.0)
Installing IQKeyboardManagerSwift (6.4.1)
Installing ListPlaceholder (1.4)
Installing LiveChat (2.0.17)
Installing MRCountryPicker (0.0.8)
Installing NVActivityIndicatorView (4.7.0)
Installing SDWebImage (4.4.7)
Installing SkeletonView (1.8.1)
Installing SkyFloatingLabelTextField (3.7.0)
Installing SwiftyJSON (4.3.0)
Installing TTRangeSlider (1.0.6)
Installing XLPagerTabStrip (8.1.1)
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There are 21 dependencies from the Podfile and 27 total pods installed.

[!] Automatically assigning platform `ios` with version `11.0` on target `LCWidget-Pods` because no platform was specified. Please specify a platform for this target in your Podfile. See https://guides.cocoapods.org/syntax/podfile.html#platform.

No application is only for iPhone and my language version is Swift 4.2 . @kamil-szostakowski

@Hamza123Imran could you please try pod repo update and then pod install?

okay let me try. @kamil-szostakowski

Yeah Now working fine, thanks for your help : ) . @kamil-szostakowski


queue:work  command does not work

Laravel Version: 5.6
PHP Version: 7.1
Database Driver & Version:

Description:
cache driver :  file
queue driver:  database
When you have never run the queue:restart command,
Illuminate\Queue\Worker::daemon   Line 91
$lastRestart = $this->getTimestampOfLastQueueRestart();
will report an uncaught FileNotFoundException.
then the job will never run.

Can you give us the exact Laravel version and the full exception details, including message and stack trace?


Difference between "active" and "verified" flag for teams

Why is the "active" flag set to False for newly created teams? Shouldn't it be set to active? And what does it affect (in contrast to "verified")?

The semantic difference is that:
a. `is_active` should control whether a team is active and can be used; while
b. `is_verified` should control whether a team can submit.

At this time, both are NOT used to enforce the above-mentioned criteria.
We should clean this up.

Teams is_verified status will now correctly decide if they can submit or not.

There are no current plans to enforce a team's is_active status.


possible missing #[allow(unused_mut)] in component macro

https://github.com/leptos-rs/leptos/blob/3adfd334df6f4116f1a043d97e9bb33b636edf86/leptos_macro/src/component.rs#L501C33-L501C33
Issue
Recently I have been getting compiler warnings above one of my components. I do not have steps to reproduce.
Maybe solution
I could very well be wrong about this as I am not intimately familiar with the proc sides of Leptos. I believe there are some very niche scenarios where this mut self could throw a warning.
Opinions
It likely does not matters at all. On the contrary, one #[allow()] is not going to kill compile time. Could just be a desync between the proc-macro server and rust-analyzer.
Regardless, let me know if you would want one added there for safe measure, or don't want to worry about it.

It's certainly possible that the line in question is the issue. If you can provide an example of some code that produces the warning erroneously, I'd be happy to try to fix it. Otherwise, there's not really any way to know what the issue is, what's causing it, or whether the fix fixes it.


viewsWelcome#view schema definition

#91269
If I understand correctly, viewsWelcome is only enabled for "view": "scm" | "explorer" | "debug". It'd be nice to include these in the json schema definition so developers know what to put in that field.

It is available for all custom contributed tree views now! I deleted that from the schema this month :).

@alexr00 but we should still offer scm explorer and debug and idealy have this open ended that when users put in anything else they do not get an error.
Not sure if possible to be done with a json schema
fyi @joaomoreno

Yes, it is possible with json schema.


Add some JS events

Add JS events to be able to manipulate Rich Editor outside
Update public JS for Rich Editor

Thanks for your work 👍


[google_maps_flutter] Remove GoogleMapsPrivacy manifest entries from plugin after future SDK update

See https://github.com/flutter/packages/pull/6511 for full context.
Because the current release of the Google Maps SDK does not contain a manifest, the official docs for the Google Maps SDK instruct developers to download a separate bundle that has the manifest entries for version 8.4 and add it to their app. For posterity since that page will presumably change once there's a release with its own manifest:

Download the Privacy Manifest bundle for the Maps SDK for iOS: GoogleMapsPrivacy.
Extract the file to access GoogleMapsPrivacy.bundle.
Copy GoogleMapsPrivacy.bundle into your Xcode project's top level directory.

Because there's already a lot of confusion around the whole manifest rollout, and because this is not at all standard for how manifests work in SDKs, we have opted to shield package clients from this temporary anomaly by folding the contents of that bundle directly into the plugin. Because the plugin is built statically, it has the effect of automatically putting that manifest into a bundle in the app (just with a different name, but that should be irrelevant).
Long term, we don't want to keep this workaround. Most importantly, once there's a new version of the SDK with its own manifest, the contents of that manifest could change at any time, and then our version would be wrong. So once a new version comes out with a manifest, we should revert to having an empty manifest for the plugin (since the plugin code doesn't do anything requiring manifest entries).
There is one caveat here: it may be that the first version that has a manifest also drops iOS 14 support. If that happens, we will have to decide between:

Removing our manifest entries, setting the min SDK version to that version, and dropping iOS 14 support.
Removing our manifest entries, not changing the constraints, and documenting in the README that users supporting iOS 14 have to do the GoogleMapsPrivacy bundle workaround themselves, manually.
Keeping our manifest entries indefinitely (in which case they will be duplicative, and potentially over time include things that aren't actually being done any more by newer SDK versions, although that seem relatively unlikely).

Any news about this please ?

After updating google_maps_flutter and running a privacy manifest analyzer on my project it still points to missing descriptions:
Analyzing GoogleMaps ...
⚠  Missing privacy manifest file!
API usage analysis result(s): 15
[0] NSPrivacyAccessedAPICategoryFileTimestamp:stat,NSURLContentModificationDateKey,NSURLCreationDateKey:./Pods/GoogleMaps/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64/GoogleMapsBase.framework/GoogleMapsBase
[1] NSPrivacyAccessedAPICategoryDiskSpace:NSFileSystemFreeSize:./Pods/GoogleMaps/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64/GoogleMapsBase.framework/GoogleMapsBase
[2] NSPrivacyAccessedAPICategoryUserDefaults:NSUserDefaults:./Pods/GoogleMaps/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64/GoogleMapsBase.framework/GoogleMapsBase
[3] NSPrivacyAccessedAPICategoryFileTimestamp:stat,NSURLContentModificationDateKey,NSURLCreationDateKey:./Pods/GoogleMaps/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64_x86_64-simulator/GoogleMapsBase.framework/GoogleMapsBase
[4] NSPrivacyAccessedAPICategoryDiskSpace:NSFileSystemFreeSize:./Pods/GoogleMaps/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64_x86_64-simulator/GoogleMapsBase.framework/GoogleMapsBase
[5] NSPrivacyAccessedAPICategoryUserDefaults:NSUserDefaults:./Pods/GoogleMaps/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64_x86_64-simulator/GoogleMapsBase.framework/GoogleMapsBase
[6] NSPrivacyAccessedAPICategoryFileTimestamp:NSFileCreationDate,NSFileModificationDate,NSURLContentModificationDateKey:./Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64/GoogleMaps.framework/GoogleMaps
[7] NSPrivacyAccessedAPICategorySystemBootTime:systemUptime:./Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64/GoogleMaps.framework/GoogleMaps
[8] NSPrivacyAccessedAPICategoryUserDefaults:NSUserDefaults:./Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64/GoogleMaps.framework/GoogleMaps
[9] NSPrivacyAccessedAPICategoryFileTimestamp:NSFileCreationDate,NSFileModificationDate,NSURLContentModificationDateKey:./Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64_x86_64-simulator/GoogleMaps.framework/GoogleMaps
[10] NSPrivacyAccessedAPICategoryUserDefaults:NSUserDefaults:./Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64_x86_64-simulator/GoogleMaps.framework/GoogleMaps
[11] NSPrivacyAccessedAPICategoryFileTimestamp:stat,lstat:./Pods/GoogleMaps/Maps/Frameworks/GoogleMapsCore.xcframework/ios-arm64/GoogleMapsCore.framework/GoogleMapsCore
[12] NSPrivacyAccessedAPICategorySystemBootTime:mach_absolute_time:./Pods/GoogleMaps/Maps/Frameworks/GoogleMapsCore.xcframework/ios-arm64/GoogleMapsCore.framework/GoogleMapsCore
[13] NSPrivacyAccessedAPICategoryFileTimestamp:stat,lstat:./Pods/GoogleMaps/Maps/Frameworks/GoogleMapsCore.xcframework/ios-arm64_x86_64-simulator/GoogleMapsCore.framework/GoogleMapsCore
[14] NSPrivacyAccessedAPICategorySystemBootTime:mach_absolute_time:./Pods/GoogleMaps/Maps/Frameworks/GoogleMapsCore.xcframework/ios-arm64_x86_64-simulator/GoogleMapsCore.framework/GoogleMapsCore
🛠  Descriptions for the following required API reason(s) may be missing: 4
[0] NSPrivacyAccessedAPICategoryFileTimestamp
[1] NSPrivacyAccessedAPICategoryDiskSpace
[2] NSPrivacyAccessedAPICategoryUserDefaults
[3] NSPrivacyAccessedAPICategorySystemBootTime

@AhmedLSayed9 This issue is not about the fact that the wrapped SDK doesn't have a manifest, it's about removing our workaround once it does.

9.0.0 was just released, which includes the privacy manifest:
https://github.com/googlemaps/ios-maps-sdk/compare/8.4.0...9.0.0#diff-c08eba4024fb7bdc0c5e8c3a94ce3dc325e1370e6766bf7853667e6ad014610dR1
However, it increased the target to iOS 15.


Fix build config

Short description
There were some issue in the build config of the flutter app. Types were wrong and we don't need the features flag verification for android, i think. Also the bundleId was wrong for sozialpass.
Proposed changes

remove featureFlags from android
rename to buildFeatures since it was misleading and using same name
adjust bundleIdentifier

Side effects

not sure where this buildFeatures former featureFlagsfor android were used. any ideas @michael-markl or @sarahsporck ?

I think there was / is? a feature flag verification that told the app whether the verification (Ausweisen) tab should be shown (and possibly if CAMERA permission should be requested).

I think there was / is? a feature flag verification that told the app whether the verification (Ausweisen) tab should be shown (and possibly if CAMERA permission should be requested).

yea this is true but thats a common featureFlag for both platforms and i doesn't make sense to put it only to android.
Even your point with the camera permission couldn't be true but there is not check for permission.
I think we shouldn't use featureFlags  for android builds. I just found the featureFlags used in app/build.gradle an renamed them

I'm wondering whether we should hide the location button and the In meiner Nähe suchen button in Floss builds, as location won't work anyways.


ERRORS

0.7.0
CraftBukkit version git-Spigot-6c9b0a1-de5c261 (MC: 1.8.8) (Implementing API version 1.8.8-R0.1-SNAPSHOT)
Plugins (40): MotdManager, CoreProtect, Ridemycraft, ArmorColorChanger, GUICalculator, WorldEdit, Installer, HealthBar, RolePlayCalendar, Essentials, GroupManager, AutoBroadcaster, Aspiire-public, CrackShot, StopCrafting, Chairs, MinetopiaATM, Multiverse-Core, ProtocolLib, WorldGuard, pvpWhitelist, SignEdit, AnvilBlock, Multiverse-Inventories, Rename, cShortcut, EssentialsChat, MaintenanceMode, Vault, EssentialsSpawn, UndineMailer, ArmorWeight, Titlebar, LWC, HolographicDisplays, CommandSigns, CraftHeads, OnTime, ChestCommands, ServerSigns
Spigot
IDK
THE ERROS:
Error fetching hand item: java.lang.IllegalArgumentException
&
incoming packet not found 79 state: HANDSHAKE

Please follow the issue template, that way we will be able to actually assist you.
Could you post the full log of your console to www.pastebin.com?
I'll look into this, but I'm not sure if I'm able to help with this little information.

I saw you also reviewed our plugin. If we fix this issue, could you please remember to update your review? It would mean a lot to us, thanks!

"incoming packet not found 79 state: HANDSHAKE" is not given by version 0.7.0.
Reloads are not supporting / your server is lagging. Most likely the first.


Build aarch64 wheels

From v1.8.0, cibuildwheel allows for building non-native architectures with the CIBW_ARCHS_LINUX option.
See https://cibuildwheel.readthedocs.io/en/stable/options/#archs for more details.

@davidism Any thoughts on this?

@davidism Any thoughts on this?

See #134, #147, and #152 for previous attempts. It looks like support is pretty good now. However, I feel like the major source that started these requests is Mac's announcement of moving to ARM, which this doesn't cover. Linux systems are much more likely to have a compiler available and enough power to compile this very small library. Additionally, while the Qemu support is much simpler than the one proposed in #152, it's still introducing another part that I don't understand to the build system.
Overall I'm still hesitant to add this, as I'd really prefer to wait until GitHub offers native support, which is bound to happen eventually.

See #134, #147, and #152 for previous attempts. It looks like support is pretty good now. However, I feel like the major source that started these requests is Mac's announcement of moving to ARM, which this doesn't cover. Linux systems are much more likely to have a compiler available and enough power to compile this very small library. Additionally, while the Qemu support is much simpler than the one proposed in #152, it's still introducing another part that I don't understand to the build system.
Overall I'm still hesitant to add this, as I'd really prefer to wait until GitHub offers native support, which is bound to happen eventually.

Looks like https://github.com/joerick/cibuildwheel/pull/484 is working on cross compile support for Mac, and it will look fairly similar to this when it's in. Probably not worth it to hold out for native envs for Linux or Mac on GitHub. Hopefully the qemu action becomes unnecessary eventually, but for now it's probably the simplest it's going to get.

Looks like https://github.com/joerick/cibuildwheel/pull/484 is working on cross compile support for Mac, and it will look fairly similar to this when it's in. Probably not worth it to hold out for native envs for Linux or Mac on GitHub. Hopefully the qemu action becomes unnecessary eventually, but for now it's probably the simplest it's going to get.

Thanks for working on this!

Thanks for working on this!

Thanks for merging. Any idea on when the aarch64 wheels show up in PyPI?

Thanks for merging. Any idea on when the aarch64 wheels show up in PyPI?

Sorry, no timeline for that. Plan for releasing 2.0 is "soon". I'm also backporting this to 1.1.x, but I have to mess with the config a bit more.

Sorry, no timeline for that. Plan for releasing 2.0 is "soon". I'm also backporting this to 1.1.x, but I have to mess with the config a bit more.

1.1.1 wheels are updated with the new envs. https://pypi.org/project/MarkupSafe/1.1.1/#files

1.1.1 wheels are updated with the new envs. https://pypi.org/project/MarkupSafe/1.1.1/#files

@davidism Thanks a bunch!

@davidism Thanks a bunch!


Use .str rather than .message to print errors.

This helps because IOError does not assign `message', but str prints
both the path and the error that occurred.
Old behavior:
$ bin/1pass foo
1pass: Error:

New behavior:
$ bin/1pass foo
1pass: Error: [Errno 2] No such file or directory: '/home/jorgen/Dropbox/1Password.agilekeychain/data/default/encryptionKeys.js'

Fixes issue #7.

@AdamIsrael LGTM 👍


Inline the service worker into the index.html for performance

We save 1 RTT by loading the service worker with the first html

Closing as no solution came up.


[rc] Pin libprotobuf <4

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Adding it to zip_keys does not work.

@conda-forge-admin, please rerender


bump elixir_sense to latest commit

iex -v 1.17.3
erl -v 27.1.2
Due to my ElixirLS constantly crashing as soon as I open  in nvim with elixir-tools.nvim I went down some debugging and got those logs: https://gist.github.com/dennym/d2bc78af479c22c918d4408f48e465cc
While trying to find out why eiixir_sense is failing to compile I saw that there were recent changes to it coming from elixir-ls repo which haven't been yet utilized in itself.
This PR should pick up all the recent changes of elixir_sense and then should be also automatically available for latest elixir-tools.nvim
Unfortunately I currently don't have the whole setup of repositories to be able to test if it removes the error I am getting but at least this dependency is up to date again and mix test succeeds locally.
Edit:
On further inspection I found a way to use my custom fork with the new changes in elixir-tools.nvim and the lsp logs can be found here:
https://gist.github.com/dennym/fabc94c57f76085380cc0b891dd856c9
There seem way more warnings which can be mostly ignored but it still has issues compiling elixir_sense but this time on some some other piece.
I would love to help but do not really know where to start on this complexity. The pity is that elixir-tool.nvim  and/or elixir-ls are completely not usable when opening any elixir code.

Those error indicates you have invalid incompatible versions somewhere. Are you using a release installed via https://github.com/elixir-lsp/elixir-ls?tab=readme-ov-file#detailed-installation-instructions or https://github.com/elixir-lsp/elixir-ls?tab=readme-ov-file#building-and-running?

I use the elixir-ls latest install which gets installed through elixir-tools.nvim
:LspInfo
LSP configs active in this buffer (bufnr: 3) ~
- Language client log: ~/.local/state/nvim/lsp.log
- Detected filetype: `elixir`
- 1 client(s) attached to this buffer
- Client: `ElixirLS` (id: 1, bufnr: [3])
  root directory:    ~/Projects/elixir-ls/
  filetypes:
  cmd:               ~/.cache/nvim/elixir-tools.nvim/installs/elixir-lsp/elixir-ls/tags_v0.22.0/1.17.3-27/language_server.sh
  version:           `?` (Failed to get version) Tried:
  `/home/denym/.cache/nvim/elixir-tools.nvim/installs/elixir-lsp/elixir-ls/tags_v0.22.0/1.17.3-27/language_server.sh --version`
  `/home/denym/.cache/nvim/elixir-tools.nvim/installs/elixir-lsp/elixir-ls/tags_v0.22.0/1.17.3-27/language_server.sh -version`
  `/home/denym/.cache/nvim/elixir-tools.nvim/installs/elixir-lsp/elixir-ls/tags_v0.22.0/1.17.3-27/language_server.sh version`
  `/home/denym/.cache/nvim/elixir-tools.nvim/installs/elixir-lsp/elixir-ls/tags_v0.22.0/1.17.3-27/language_server.sh --help`

Running the version command manually returns elixir-ls v0.22.0 which also fits the path. I guess I gonna dig around at elixir-tools-nvim for a bit and figure out why its so outdated. I will report back and handle the issue accordingly.

Ok I did a bit tinkering and turns out that elixir-tools.nvim is a bit funky how it handles the options and default values.
I did reset everthing and installed HEAD of elixir-ls with elixir-tools and confirmed that its HEAD but unfortunately it still crashes on elixir_sense compiling: https://gist.github.com/dennym/ce48cb8c88fcfa487f03fd19aac3bd5c
Additionally I tried the  tag to the latest v0.24.1 as elixir-ls install but this returns basically the same error output as HEAD.
Manually running mix deps.compile --force elixir_sense runs successful with just 2 warnings. Which is even more confusing since I have just a regular elixir/erlang setup as recommended in the install guides and should not provide any funny business in the nvim space.

Why are you intending on using HEAD? It currently contains some work in progress. Check out a tagged release commit and build a release as described in the readme. Otherwise download a release from github


feat: nowhere dense and meagre sets

Define nowhere dense and meagre sets and show their basic properties.
Meagre sets are defined as the complement of a comeagre(=residual) sets
(and shown to be equivalent to the standard definition); we deduce their API from the API for comeagre sets.

I'm still pretty new to Lean, hence am open to learning new and exciting ways to golf this! :-)
Unresolved questions

Where should these results go? Should they stay in a separate file or be merged with GDelta.lean? (Is there a file FSigma.lean?
Does mathlib prefer American spelling? Then I can adjust :joy:
I'm very open to suggestions for better lemma names, still learning here.

Had some confusion with git branches. Re-created at #7180.


pymesos doesn't install on python 3.7

pymesos 0.3.12 does not install from pypi on python 3.7.  This is due to the http_parser package C code not being compatible with py3.7.
http_parser appears to be no longer maintained, with the last pypi release in 2013.  Suggest dropping this package.
pymesos-error.txt

Temporary repair https://github.com/douban/pymesos/pull/123

We already tried this, its does not allow pymesos to be installed from pypi, so it doesn't solve our problem.  Please reopen ticket

Sorry for this. Once this pr get merged, I'll update the install requirements and publish it ASAP.

Done https://pypi.org/project/pymesos/0.3.15/


nixos: systemd-homed support

Description of changes
Fixes #91243 #79253
This change involves two new modules, one for userdbd and another for homed.
I've been daily driving this for awhile, and I can verify that it works with fprintd as well.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Thanks for the PR! However, this needs to target staging due to the amount of rebuilds. Can this be rebased on staging? (Please check the contribution guideline on how to rebase this on staging without causing a mass ping)

Alright, let's cook this in staging :-) Thanks for the PR! :-)


Report an issues : Selected number display problem

The issue was found at latest bootstrap-select v1.6.5.
When clicking "select all" and then un-select a few items, it would keep showing 5 selected (Correct total selected items number is 3)

Continue with this case, if I re-select some of the items again (but not all items), The text would show "All selected (6)"

Here is my code for the case:
JavaScript
<script type="text/javascript">
    $(function () {
        $('#skill-filter').multiselect({ includeSelectAllOption: true });
    });
</script>

HTML
<select id="skill-filter" title="Skill" name="skill" class="form-control" multiple="multiple">
    <option value="indo">Skill 1</option>
    <option value="fili">Skill 2</option>
    <option value="fili">Skill 3</option>
    <option value="fili">Skill 4</option>
    <option value="fili">Skill 5</option>
    <option value="fili">Skill 6</option>
</select>

Sorry for posted this issues at incorrect repository


🌐 Language request: Arabic

🌐 Language name (native)
العربية
🌐 Language code
ar

Arabic is RTL indeed, but if mean mirror-flipping the entire thing, I don't think it's necessary, we're used to items staying in same location when switching EN-->AR. Especially if it's gonna take your considerable effort to do it.

@nitpack Okay, great! I added Arabic. I'll look into whether I can change the layout to RTL, but at the moment it is just LTR. Thanks for your contribution :)


omnisharp-roslyn: 1.39.6 -> 1.39.7

Description of changes
https://github.com/OmniSharp/omnisharp-roslyn/releases/tag/v1.39.7

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2347


STOR-1688: Chore: add .snyk file to ignore false positives

/label px-approved
/label docs-approved
/label qe-approved

/retest

/lgtm

/retest

/retest

/retest

/retest

/retest

/override ci/prow/e2e-vsphere-csi

oops, that was supposed to be the upgrade job (e2e-vsphere-csi already passed here)
/override ci/prow/e2e-vsphere-ovn-upgrade

come on now, this is just a .snyk file that has no impact on the build or cluster installation
/override ci/prow/e2e-vsphere

/override ci/prow/e2e-vsphere-ovn-upgrade


Error: FILE_NOT_FOUND_ERR.. if tried to access file URI 10 minutes later

Unable to reach to file if there is a delay in using the URI within 10 min of selecting it from iCloud..not sure if OS is clearing the tmp files.....but 10 min is too short...

Did you find the solution?

I think maybe the file is deleted by os, since it's copied to the temp directory


Rename randaugment to rand_augment

What does this PR do?
Currently, randaugment is inconsistently named compared to the rest of the methods. It should be rand_augment. This PR renames the files/imports/docs. Along for the ride, we fix the functional API docs which calls the wrong method.
What issue(s) does this change relate to?
N/A

Jk I guess there's a lot of places without _. Closing


VLAZ: Watch stoprodent.com

VLAZ requests the watch of the watch_keyword stoprodent\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

stoprodent\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


add to calendar option

provide an option to save an event to my calendar.
there are probably jQuery plugins that can support adding an event to the calendar of the major email clients.

e.g.: https://github.com/carlsednaoui/add-to-calendar-buttons

I like it! If possible it would be nice to keep things in Vue land. I think this library could work though: https://github.com/nicolasbeauvais/vue-add-to-calendar

Actually I don’t think that library you posted requires jQuery - that might be the better way to go since it has more options as well

yea only downside is that the repo was last updated ~6 years ago, it still works ok (from their live demo)

yea only downside is that the repo was last updated ~6 years ago, it still works ok (from their live demo)

Sadly, the mantainer of this repo passed away. https://github.com/carlsednaoui/add-to-calendar-buttons/issues/36
One of the contributors forked the repo and mantaine this one: https://github.com/commonpike/add-to-calendar-buttons


Limiting the number of entities in a one-to-many relationship

How can I get, in a one-to-many relationship, a limited number of entities?
In Laravel I use the code:
$limit = 12;
$persons = Person::get()
    ->map(function (Person $person) use ($limit) {
        return $person->setRelation('media', $person->media()
            ->latest('added_at')
            ->take($limit)
            ->get());
    });

In this example, I get only two entities for all parents:
PersonModel.query()
    .with('media', (query => {
        query.limit(2)
    }))
    .get()

[
  {
    "id": 1,
    "loading": false,
    "mediaCount": 68,
    "media": []
  },
  {
    "id": 2,
    "loading": false,
    "mediaCount": 11,
    "media": []
  },
  {
    "id": 3,
    "loading": false,
    "mediaCount": 48,
    "media": [
      {
        "id": 6082,
        "personId": 3,
        "desription": ""
      },
      {
        "id": 6083,
        "personId": 3,
        "desription": ""
      }
    ]
  }
]

@tweaker Hi! Thank you so much for the report! Yeah, Vuex ORM eager load works same as Laravel eager load, so this is by design. You can do something like below I think. Would it make sense to you?
PersonModel.query().with('media').get().map((person) => {
  person.media = person.media.slice(0, 2)

  return person
})

@tweaker Hi! Thank you so much for the report! Yeah, Vuex ORM eager load works same as Laravel eager load, so this is by design. You can do something like below I think. Would it make sense to you?
PersonModel.query().with('media').get().map((person) => {
  person.media = person.media.slice(0, 2)

  return person
})

Thank you very much for your answer! It turned out I need sorting.
It turned out like this:
PersonModel.query()
    .orderBy('updatedAt', 'desc')
    .get()
    .map(function (person) {
        person.media = MediaModel.query()
            .where('personId', person.id)
            .orderBy('addedAt', 'desc')
            .limit(15)
            .get();
        return person
    });

#399
@tweaker Thank you for trying out! Yeah, that looks good. But in that case, you could first filter Media using eager load constraint. It'll save executing extra query so it might be a bit faster.
PersonModel.query()
    .with('media', function (query) {
        query.orderBy('addedAt', 'desc')
    })
    .orderBy('updatedAt', 'desc')
    .get()
    .map(function (person) {
        person.media = posts.media.slice(0, 15)

        return person
    })

I'll be closing this issue for now. Thank you so much for the feedback! 🤝


swab test invitation with symptoms ended?

should we send a swab test invitation if symptoms have ended? I don't think we should


Some UI elements flipped in graphing mode in RTL

Describe the bug
Some UI elements flipped in graphing mode in RTL

Expected behavior
All text and UI elements respect RTL languages.
Screenshots

Additional context
Reported on Reddit
Requested Assignment
I'm just reporting this problem.  I don't want to fix it.

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

I don't think the layout should be plainly mirrored the way it is here. I have never seen the numbers on a numpad to be swapped this way for Arabic and also as far as I know charts in schools are taught the same way they are in LTR, i.e. negative numbers to the left, positive to the right. The enter key arrow pointing this way is also not the best either. Perhaps have your native speaker colleagues test the localizations?
Note that the situation with Hebrew might be different.

I am a native speaker, and I can say the situation with Hebrew is the same. The numbers in Hebrew (and everything math related) is LTR. In theory, only the location of the sidebar should change.

Can we get an update on this? The graph is still mirrored.
If you need help with the expected behavior in Right To Left flowing languages:

X increases in value from left to right
Y increases in value from bottom to top
Numbers are written with most significant number furthest to the left

Because of this behavior, the graph control can be wrapped in an explicit FlowDirection="LeftToRight" assignment, which would resolve all problems.


Auto dispose after first listener

Riverpod version 2.0.0-dev.4 adds a disposeDelay feature to all autoDispose providers and to ProviderContainer/ProviderScope. This configures the amount of time before a provider is disposed when it is not listened.
To avoid timing issues, it would be nice to add a "auto dispose after the provider is listened to once" mode, which make the provider auto disposable only after it is listened to once.
Example:

Some function on screen A initalizes a provider with some initial value and then navigates to screen B.
Only screen B watches the provider.
Once screen B is disposed, the provider should be disposed.

Only screen B watches the provider.

I would suggest have A listen to the provider until navigating to B

The nature of the use case is that A is not interested in this provider.
A classic example is a master/details scenario:

Screen A presents a list of items
Screen B allows to edit a single item
The provider represents the item that is currently being edited.

This scenario is very common and the library doesn't seem to provide an easy way to handle it.

Maybe it's worth expanding on what "initializing with some initial value" means and also explain what's the problem you're currently facing

The provider will be initalized with the item that was selected in the list.
Then the app will navigate to screen B where you can edit the properties of the item.

The provider will be initalized with the item that was selected in the list.

Right, but what exactly does this involve?

Code example:
void onItemSelected(BuildContext context, WidgetRef ref, Item selectedItem) {
  ref.read(editedItemProvider.notifier).setItem(selectedItem);
  Navigator.of(context).pushNamed(screenB);
}

class Item {
  final String name;
  const Item(this.name);

  Item copyWith(String? name) => Item(name ?? this.name);
}

final editedItemProvider = StateNotifierProvider.autoDispose<EditedItemNotifier, Item>((ref) {
  return EditedItemNotifier(ref: ref);
});

class EditedItemNotifier extends StateNotifier<Item?> {
  final Ref ref;

  EditedItemNotifier({required this.ref}) : super(null);

  void setItem(Item item) {
    state = item;
  }

  void updateName(String newName) {
    state = state?.copyWith(newName);
  }
}

And why don't you want to set disposeDelay in this case?

It would work, but relying on a specific timeout is more error prune while relying on adding/removing a listener is exact.
With a timeout you alaso hold the state longer than you actually need it which is a disadvantage.
This scenario is very common in many apps and it would be nice to have this if it's a small feature to implement.

I agree in this case, even tho disposeDelay help the issuw. Still uncertain how long it should hold the state. There is cases when I switch screen and then back to the old screen. I would like to dispose it immediately and not delay the dispose.

I've been dealing with this same issue - my use-case is initializing a AutoDisposing StateNotifierProvider that is used to cache form values until submission - the initialization occurs when "master" form widget is loaded, but this widget does not care about the state of the provider; the detailed form widgets subscribe to different parts of the form state via the provider.
I cannot use auto-dispose unless the master watches the provider, causing rebuilds in the entire tree - having the auto-dispose occur only after at least one listen would solve my issue.

Well ultimately you can do that yourself already
Provider((ref) {
  ref.onCancel(ref.invalidateSelf);
}
``

This effectively produces the same result as `autoDispose`, without the state getting destroyed during navigation

While the proposal is interesting, I'm not sure it's ultimately a good idea.
I could see a few flaws:

what if the provider is never listened?

what if you have:
 final a = Provider.autoDispose(..., waitUntilListenedBeforeDispose);

 final b = Provider((ref) {
    ref.watch(a);
    return Something();
 });

// inside some widget:
ref.read(b);
Navigator.push();

That'd still cause a to be disposed, since it's temporarily listened by b

If we want to do something other than disposeDelay (which I personally think is good enough for the problem described), I'd personally prefer having a way to make A temporarily listen to the provider until B is poped
Like maybe:
Button(
  onTap: () async {
    final sub = ref.listen(provider, (prev, value) {});
    await Navigator.push();
    sub.close();
  },
)

While the proposal is interesting, I'm not sure it's ultimately a good idea.
I could see a few flaws:

what if the provider is never listened?

what if you have:
 final a = Provider.autoDispose(..., waitUntilListenedBeforeDispose);

 final b = Provider((ref) {
    ref.watch(a);
    return Something();
 });

// inside some widget:
ref.read(b);
Navigator.push();

That'd still cause a to be disposed, since it's temporarily listened by b

I agree with you, that this will cause a issue. But tbh when i set the provider state and navigate screen. First problem i'm bit unsure how long the disposeDelay should last. Maybe navigate screen takes a microsecond or couple seconds. Then i have the problem with that i would like to use the state in screen B that is setted from screen A. But i would like to dispose the state immediately after i leave screen B and not delay it.

Maybe navigate screen takes a microsecond or couple seconds

Navigating to a screen is not duration based. It's event-loop based. It'll take one cycle of the event loop
As such, any non-zero duration will do.
Also, "disposing immediately" doesn't matter. What's wrong with delaying the dispose by a few seconds?

One more thing, the fact that this feature doesn't solve ALL scenarios is irrrelavnt since it obsivously helps solve some common scenarios.

It is important, since there are workarounds.
Adding a new API comes with a significant cost

How exactly can we achieve this behaviour ourselves with the current implementation?

You can do the ref.listen variant I showed by doing:
final container = ProviderScope.containerOf(context);
final sub = container.listen(...);
await push();
sub.close();

This works today.
And I have an streamlining this a bit by adding a WidgetRef.listen variant which returns the subscription instead of being used inside build like the current one.

I agree with others that a temporary listener, or time based condition, feel awkward - what if the detailed components that subscribe to the provider themselves depend on some other unknown time-based async event, like fetching data before subscribing; the delay can't be set programmatically, but a dispose after first listen can.

I agree with others that a temporary listener, or time based condition, feel awkward - what if the detailed components that subscribe to the provider themselves depend on some other unknown time-based async event, like fetching data before subscribing; the delay can't be set programmatically, but a dispose after first listen can.

You can close the temporary listener whenever you want.
Same goes for the initialization. You'll call ref.read when you want. If your onTap has other async functions, they'd likely execute before the ref.read – since the read will depend on them.

@rrousselGit
The entire point of this feature is separation of concerns.
Creating an ad-hoc listenter where it is not needed seems a bit weird.

There's no reason for it to feel weird. It's a fairly common pattern for testing
final container = ProviderContainer();
final sub = container.listen(autoDisposeProvider, (prev, value) {});

expect(sub.read(), 42);

That's the expected way to "read" autoDispose providers.

Just for the sake of the example, if the navigation to the screen that uses that auto disposable provider is done in 10 different places, each one would have to be aware of this and create its own dummy listener, instead of encapsulating this behaviour in the provider itself.

What I really want to avoid is adding an option flag.
Options tend to increase the complexity of the API quite a bit.
If this behavior is really desirable, I would prefer having a breaking change and making this the new behavior for all autoDispose providers.
Having such behavior as a flag IMO is a bad idea
It's actually something I originally wanted to do for the 1.0.0 (cf https://github.com/rrousselGit/river_pod/issues/531).

I agree with option flag it can get narly, but i feel like it's described it should be the default behaviour of autoDispose

Example:
Some function on screen A initalizes a provider with some initial value and then navigates to screen B.
Only screen B watches the provider.
Once screen B is disposed, the provider should be disposed.

@talent-apps
I wonder if this solution solves your problems?

You read on screen A without .autoDispose
When screen B is disposed, you call invalidate() to dispose the provider manually.

@XuanTung95
Interesting idea, it's worth testing it.

Might as well do what I suggested before
https://github.com/rrousselGit/river_pod/issues/1329#issuecomment-1085868131

final sub = ref.listen(provider, (prev, value) {});

I've tested it out and seems not to work. The value is disposed when i switch to screen2 but is accessible when i go to screen3
final counterProvider = StateProvider.autoDispose<int>((ref) {
  ref.keepAlive();
  ref.onCancel(ref.invalidateSelf);
  return 0;
});

class Screen1 extends ConsumerWidget {
  const Screen1({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return Center(
      child: ElevatedButton(
        child: const Text("Go to screen2"),
        onPressed: () async {
          ref.read(counterProvider.state).state = 10;
          await Navigator.push(context, MaterialPageRoute(builder: (context) => const Screen2()));
        },
      ),
    );
  }
}

class Screen2 extends ConsumerWidget {
  const Screen2({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final counter = ref.watch(counterProvider);
    return Center(
      child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: [
          Text(counter.toString()),
          ElevatedButton(
            child: const Text("Go to screen3"),
            onPressed: () {
              ref.read(counterProvider.state).state = 10;
              Navigator.push(context, MaterialPageRoute(builder: (context) => const Screen3()));
            },
          ),
        ],
      ),
    );
  }
}

class Screen3 extends ConsumerWidget {
  const Screen3({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final counter = ref.watch(counterProvider);
    return Center(
      child: Text(counter.toString()),
    );
  }
}

Well that's doing exactly what this issue is suggesting
This feature request would have the same problem.

But to be fair, it sounds like you folks want cacheTime instead of disposeDelay

ref.read should maintain the state of auto-dispose providers. I dont see why it gets disposed when clearly listening to the provider on next screen. CacheTime is great, but I dont think it's the solution to this problem.
Setting a time may cause it to dispose to early or keep the state for to long.

cacheTime is the expected solution. Destroying the value as soon as the user leaves the screen is rarely the expected UX.
Users typically would expect that quickly leaving and coming back to a screen bypasses the loading state.
If anything, cacheTime should default to a few minutes. That's how it is in other techs

But to be fair, it sounds like you folks want cacheTime instead of disposeDelay

@rrousselGit

I don't think people will like magic number in the code.
I think the problem is .autoDispose does not work as expected in some special cases. Changing the behavior of .autoDispose might cause other problems.
I'm thinking about giving more control to dispose a provider. Like, turn on/off autoDispose at run time or smth. So if provider is disposed at the wrong place, just tell people to turn on/off autoDispose at the right time. What do u think?

cacheTime is the expected solution. Destroying the value as soon as the user leaves the screen is rarely the expected UX. Users typically would expect that quickly leaving and coming back to a screen bypasses the loading state.
If anything, cacheTime should default to a few minutes. That's how it is in other techs

Then you are stuck with a state for to long. E.g if you fetch news, switch screen and go back. I would like to refetch the news. By dispose the old one as soon i left. In this case i dont like to have magic numbers.

Then you are stuck with a state for to long. E.g if you fetch news, switch screen and go back. I would like to refetch the news. By dispose the old one as soon i left. In this case i dont like to have magic numbers.

That's only temporary. There's a separate feature in progress that'll separate "call dispose" from "keep the value"

I'm thinking about giving more control to dispose a provider. Like, turn on/off autoDispose at run time or smth. So if provider is disposed at the wrong place, just tell people to turn on/off autoDispose at the right time. What do u think?

You already have all the control you need
there's ref.keepAlive/onCancel/onResume/invalidateSelf and cacheTime+disposeDelay, and also the the typical "listen + close subscription"

You already have all the control you need
there's ref.keepAlive/onCancel/onResume/invalidateSelf and cacheTime+disposeDelay, and also the the typical "listen + close subscription"

@rrousselGit
OK I think that will work.
Just some comment.

keepAlive is in AutoDisposeRef so I need to store ref for every provider in order to call keepAlive. Could you make it easier to use?
If I have a normal provider or family which is not .autoDispose. Later I want to .autoDispose it, could I have a method dontKeepAlive? The workaround would be to create .autoDispose and set keepAlive then store the KeepAliveLink, then close() it, which is a lot of code.

@rrousselGit
Re: "Destroying the value as soon as the user leaves the screen is rarely the expected UX.
Users typically would expect that quickly leaving and coming back to a screen bypasses the loading state."
Not sure why you assume this. The scenario that was presented earlier (list of items and a screen to edit an existing item) requires initialization of the provider every time rather than caching a previous value.

keepAlive is in AutoDisposeRef so I need to store ref for every provider in order to call keepAlive. Could you make it easier to use?

keepAlive is private to the provider.
If you want to maintain the state of a provider from outside the provider, use listen+close

If I have a normal provider or family which is not .autoDispose. Later I want to .autoDispose it, could I have a method dontKeepAlive? The workaround would be to create .autoDispose and set keepAlive then store the KeepAliveLink, then close() it, which is a lot of code.

I don't understand what you're trying to do. Could you share some code?

Not sure why you assume this. The scenario that was presented earlier (list of items and a screen to edit an existing item) requires initialization of the provider every time rather than caching a previous value.

Re-initializing the provider when re-opening the screen and keeping the previous state are two different things
They aren't mutually exclusive, and you can do both at the same time. As I mentioned, there's a wip feature for this.

@rrousselGit
The suggested solution of https://github.com/rrousselGit/river_pod/issues/1329#issuecomment-1085868131 doesn't seem to work. How should we implement it with the current lib?

It should work. What do you mean by "doesn't work"?

Check out https://github.com/rrousselGit/river_pod/issues/1329#issuecomment-1086828636
"The value is disposed when i switch to screen2"

I don't understand what you're trying to do. Could you share some code?

Example:
class MyState extends ChangeNotifier {
}

final myProvider = ChangeNotifierProvider.family((ref, String id) {
  return MyState();
});

class MyWidget extends ConsumerStatefulWidget {
  const MyWidget({Key? key}) : super(key: key);

  @override
  _MyState createState() => _MyState();
}

class _MyState extends ConsumerState<MyWidget> {
  final String myId = "id";

  @override
  void initState() {
    super.initState();
  }

  @override
  void dispose() {
    // ref.invalidate(myProvider(myId)); // <-- this will cause the provider to be disposed immediately.

    ref.autoDispose(myProvider(myId)); // <-- this will cause the provider to be disposed if there is no listener.
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    final state = ref.watch(myProvider(myId));
    return Container();
  }
}

That looks like a bug with StateProvider (& likely State/ChangeNotifierProvider)
Provider doesn't behave this way. Will fix

Well ultimately you can do that yourself already
Provider.autoDispose((ref) {
ref.keepAlive();
ref.onCancel(ref.invalidateSelf);
}
This effectively produces the same result as autoDispose, without the state getting destroyed during navigation

Check out https://github.com/rrousselGit/river_pod/issues/1329#issuecomment-1086828636
That looks like a bug with StateProvider (& likely State/ChangeNotifierProvider)

@rrousselGit
I'm confused.

ref.keepAlive() : Requests for the state of a provider to not be disposed when all the listeners of the provider are removed.
ref.onCancel(ref.invalidateSelf):  when the last listener of the provider is removed, invalidates the state of the provider.

With this code, I expected ref.onCancel(ref.invalidateSelf) will cause invalidates the state of the provider before go to screen 2 because ref.invalidateSelf is called. If the expected behavior is keeping the state during navigation then no one will understand why, it's more like a bug to me if you implement that.

With this code, I expected ref.onCancel(ref.invalidateSelf) will cause invalidates the state of the provider before go to screen 2 because ref.invalidateSelf is called.

No it won't.
ref.read does not triggers onCancel
onCancel triggers when the last listener is removed. ref.read doesn't add/remove listeners, so it won' trigger onCancel,
The bug with StateProvider is because it's implemented as two providers (StateProvider vs StateProvider.notifier, where the former "watch" the later). So with autoDispose, a listener is added then removed immediately

But I think I'll make a breaking change and:

prevent using ProviderContainer.read on autoDispose providers
make WidgerRef.read/Ref.read "listen" to the provider indefinitely (until the associated widget/provider is disposed that is)

So doing:
Button(
  onTap: () => ref.read(autoDisposeProvider.notifier).state++,
)

and then tapping the button will prevent the provider from getting disposed until the button is unmounted.

I like this idea of the breaking change. I have definitely run into problems related to those apis.

Although I guess this won't cause the provider to be disposed when leaving screen2 and we'd have to leave screen 1. 🤔

@rrousselGit
Let's consider it a bit.
I think people still want to read a provider everywhere without the need to keep it alive. If everything is "watch" then it's hard to auto dispose a provider because we need to care about every read in the whole app.
The scenario of this ticket can be solved easily by using ref.watch on screen 1, it is just folks don't want rebuild when it's not necessary.
I think we should work on how to "read" an autoDispose provider and keep it alive until it's done.

@XuanTung95
I agree that making the read API into a watch API is counter intuitive.
The scenatio that was initially presented was that screen 1 doesn't care about the provider, and therefore doesn't need to watch it, it only initialized it with some value for screen 2.

If I have a normal provider or family which is not .autoDispose. Later I want to .autoDispose it, could I have a method dontKeepAlive? The workaround would be to create .autoDispose and set keepAlive then store the KeepAliveLink, then close() it, which is a lot of code.

I don't understand what you're trying to do. Could you share some code?

@rrousselGit
I edit my example. It looks like this.
final myProvider = ChangeNotifierProvider((ref) {
  Future.delayed(Duration(seconds: 2)).then((value) {
    ref.autoDispose(); // <- this provider become autoDispose from now on
  });
  Future.delayed(Duration(seconds: 5)).then((value) {
    ref.keepAlive(); // <- back to normal
  });
  return ChangeNotifier();
});

Goal: Add 2 method .autoDispose() and .keepAlive() to Ref<State extends Object?>

.keepAlive(): works same as normal .keepAlive() of AutoDisposeRef. Maybe it return void instead of a Link object, because we can use .autoDispose() to change the behavior.
.autoDispose(): after call this method, provider work same as normal .autoDispose provider until .keepAlive() is called.

I think this feature will complete the .keepAlive() implementation you did. Allow folks to controller the life-cycle of provider more flexible.
It can solve the issue of this ticket by using .autoDispose() method once screen B is disposed.

I know, but it's only possible for .autoDispose, other providers also need to be disposed if nessesarry. The current implementation is not friendly if I don't want to use .autoDispose.

That's not a bug, that's a feature. Marking a provider as .autoDispose is critical for making hard-to-catch bugs a compilation error instead. It being necessary is voluntary and this will not be changed.

.autoDispose is critical for making hard-to-catch bugs a compilation error instead

Could you give an example bug?

This is currently voluntarily made to be a compilation error

I understand.
But it has nothing to do with my proposal. The normal provider still cannot watch an autoDispose provider. It just add a away to dispose the normal provider.

ref.autoDispose() mean I want to dispose it if there is no listener
ref.invalidateSelf() mean I want to dispose it even if there are listeners (if i don't misunderstand about this method)

They are 2 different use cases. If I call ref.autoDispose(), I should expect it do not dispose if someone is listening.
So how can it be a bug if I want it to behave that way.

On a different note, what do you think about a simplification of ref.listen + close
onTap: () {
  await ref.run(provider, (value) async {
    // provider will stay alive until the callback completes
    await Navigator.push(); // The await here will keep the provider alive until the route is poped
  });
}

On a different note, what do you think about a simplification of ref.listen + close
onTap: () {
  await ref.run(provider, (value) async {
    // provider will stay alive until the callback completes
    await Navigator.push(); // The await here will keep the provider alive until the route is poped
  });
}

This make more sense, LGTM

On a different note, what do you think about a simplification of ref.listen + close
onTap: () {
  await ref.run(provider, (value) async {
    // provider will stay alive until the callback completes
    await Navigator.push(); // The await here will keep the provider alive until the route is poped
  });
}

I think we can do the same with this.
onTap: () {
  final value = ref.read(provider);
  final link = value.keepAlive();
  await Navigator.push();
  link.close();
}

Adding run() method may be not necessary unless it is used a lot.

You cannot call keepAlive like you've described.
And you also need to handle exceptions, as if somehow code after the read throws, the provider will never get disposed.

And "go_router" package does not return Future when navigating, so it only work for Navigation 1.0.

That's not Riverpod's fault though. You can make a feature request for it in go_router's repository

It has been a while, any update on this ticket?

I'm still skeptical about this. I think this would be a hazardous thing to implement and could cause quite a bit of confusion
I'd prefer looking at a better solution. As once published, the harm done by such a feature could be enormous.
For this issue, I think a better alternative would be to give you the primitives to be able to implement this on your own.
I think the ref.onCancel/ref.onResume life-cycles are good candidates (combined with ref.keepAlive())
You should be able to use those to implement this on your own, without needing Riverpod to make this an official API.

Closing in favor of https://github.com/rrousselGit/riverpod/issues/1665. That issue would add the missing feature for implementing what's described here.

@rrousselGit
Should we reopen this?
It was closed in favor of ref.onCancel but ref.onCancel is not reliable to be used for this use-case as described at #2992 & #3759.

Nope. I have no plan to change this.
IMO this feature is too dangerous, as if the "first listener" is never added for some reason, the disposal will never happen.
We can raise new issues with regads to documenting how to init some values before pushing a route though.