That’s why I would not phrase it that nonchalantly. I see flagging a package as a last resort measure where upstream is uncooperative or hostile to a point where users need to be effectively warned about what they are getting into by using that package.
I suppose what I am looking for turned out to be proposed already: Pre-RFC: Implement dependency retrieval primitive
Assuming some packages can disable telemetry. Either a build-time flag, a wrapper that sets an argument or an env var, the maintainers applying a patch, or some other way. If it can be disabled when building the package, a flag could be added to the package expression. The value of that flag could be used to effect metadata.collectsTelemetry (or whatever is settled upon).
Something like metadata.collectsTelemetry = !disableTelemetry;
It would then leave it up to the package maintainers to either do it by default or not depnding perhaps on what upstream does. When a person concerned about telemetry sets the global flag to not allow telemetry, any package where it is disabled would not block evaluation. One downside with package expression options is the default version is the only one that gets cached, so changing it will cause local builds for that package, but that’s going to be true eiher way.
In the case of something like Flutter (or similar) which is an input to many packages it might be worth disabling it by default at build time so it doesn’t stop evaluation for anyone concerned about telemetry, when it’s a seconday dependency. Or cause massive local builds for anyone who wants to override it.
I’m not famiilar with Flutter, just from context in this thread it sounds like it sends crash reports at build time if something goes wrong, I’m not clear if or how it escapes the sandbox, so maybe it’s already effectively disabled?
I think the general intent of someone setting allowTelemetry = false is they don’t want data about them or their system being sent to third parties. So as long as maintainers make their best effort to ensure that’s true for the specific software being used even if it would normally send data, I think that accomplishes the goal.
Yeah, I don’t think flutter would like us calling flutter --disable-analytics with every single call. I think it actually exits once the analytics option is changed. I’m not sure if they even follow the do not track environmental variable. Overriding the config file is overkill too.
1 Like
People will use flutter as a development tool, eg. in dev shells, I assume, so the sandbox argument does not really fit in my opinion.