Hi everyone,
I plan to start an LSC process for UV conversion for VPython in Chromium. As an example of that, see
this CL.
Generally this should land properly because VPython has been upgraded across all clients to hold the correct version that understands these configurations. However, the issue are the mainland China users.
The new VPython introduces not only embedded UV but also a new Artifact Registry (AR) which is a different domain from the GCS that legacy VPython used. If users pass the proxy configs the same way CIPD does (through environment variables), they will not notice any difference. However, if their work networking is configured to set the proxy only for GCS calls and not the AR calls, this raises issues like
this one where the end user lacks control over the networking and is unaware that the Great Firewall affects them daily.
I suspect that some companies might have noticed the failures and have locked their depot_tools checkouts with vpython that is not calling to AR. That will work for now but will break immediately once I start upgrading Chromium code to UV configs that the old VPython cannot parse. So once they fetch the newest Chromium code, they will end up between a rock and a hard place, they will have to upgrade depot_tools and resolve the issue at a higher pace than before.
What do you think about this? Should we do something proactive for those customers or just let them be? I could keep the old VPython configuration for compatibility, but that's far from ideal. I suspect that the ByteDance might be affected by this issue as I was handling one of their engineers that suddenly went quiet, presumably as they gave up on depot_tools and locked it before the upgrade.
--