Update all python dependencies

[rogerluan]

Description

This PR updates all python dependencies we have by running pipenv update.

It requires us to move away from:

google_analytics:
- UA-18658848-13
- docs.fastlane.tools

to:

theme:
  analytics:
    gtag: G-111111111

Related PR: mkdocs/mkdocs#2253

We need to update to the right gtag value (GA4 property) which can only be fetched from fastlane's webiste analytics.google.com dashboard.

Until we update it, we'll see this:

References

This PR supersedes:

• Bump tornado from 6.1 to 6.3.3 #1208
• Bump joblib from 1.0.1 to 1.2.0 #1207
• Bump future from 0.18.2 to 0.18.3 #1206
• Bump nltk from 3.6.2 to 3.6.6 #1204
• Bump pymdown-extensions from 8.1.1 to 10.0 #1203
• Bump mkdocs from 1.1.2 to 1.2.3 #1202

[janbrasna]

It requires us to move away from: […]

We need to update to the right gtag value (GA4 property) which can only be fetched from fastlane's webiste analytics.google.com dashboard.

@rogerluan If that makes any easier the old UA stopped gathering data in mid-2023 and by mid-2024 they won't even be accessible anymore for historic purposes, so if you can't get ahold of the new GA4 value you can just shim it or disable the analytics for now — as it won't have any impact on collecting analytics — they are NOT being collected already as we speak…

[janbrasna]

BTW the fastlane.tools web last updated in 2022 also doesn't have any G–* tag GA4 ID so that isn't gathering any stats right now as well. (=Which I understand that there's no GA4 setup at all, so no ID to wait for.)

Since there's no cookie policy nag bar at docs.* and the GA would need to run in anonymous mode otherwise without that tracking consent, I'd say it's safe to completely disable the GA plugin at this time by not providing any value.

[rogerluan]

This is super helpful @janbrasna 😲 I think you're right. We wouldn't be causing any regressions 👀 might end up going with that solution after all!

[rogerluan]

It seems like RubyGems is undergoing maintenance and their servers are timing out… will check this later

[fastlane-bot-helper]

	1 Warning
⚠️	mkdocs.yml was modified - make sure no modification was made by mistake

Generated by 🚫 Danger

[rogerluan]

Looks like CI passed 🙏

[revolter]

LGTM, thanks!

[janbrasna]

Dependabot is not smart enough to pick up the changes and close the obsolete PRs:

This PR supersedes:

• Bump tornado from 6.1 to 6.3.3 #1208
• Bump joblib from 1.0.1 to 1.2.0 #1207
• Bump future from 0.18.2 to 0.18.3 #1206
• Bump nltk from 3.6.2 to 3.6.6 #1204
• Bump pymdown-extensions from 8.1.1 to 10.0 #1203
• Bump mkdocs from 1.1.2 to 1.2.3 #1202

so if anyone can do the honours and close them out? Thanks 💋

(For this reason I'd usually use closing keywords in the PR descriptions to explicitly make sure they get closed upon merging, even if the bot leaves them dangling… 🤦)

[revolter]

Good catch, thanks! ❤️

---

(For this reason I'd usually use closing keywords in the PR descriptions to explicitly make sure they get closed upon merging, even if the bot leaves them dangling… 🤦)

Are you sure that you can auto close other PRs (not issues) from a PR? 🤔 I know that it can auto close issues: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue.

[rogerluan]

Yeah it works with PRs too :) I've used this before IIRC

[rogerluan]

Dependabot could auto close those open PRs (it is smart enough actually! 😝), but I think that just happens when it runs again (which, for this repo, I think that happens once a month only 😁) — good call!

[revolter]

Because we didn't interact with it lately, it was paused (https://github.blog/changelog/2023-01-12-dependabot-pull-requests-pause-for-inactivity/), and that's why it didn't close them.

[janbrasna]

@revolter Yup, it may not necessarily be designed to, or documented for that matter, but works:

@rogerluan I thought so and checked before posting for dependency schedule settings to save unnecessary notifications… but that's probably somewhere in repo settings as there's no dependabot yml config file around here. Anyways I think it would take some time and maybe minor mkdocs bumps for it to realise the "*" is currently already satisfied by the installed version anyways, and close out the old PRs. (It's good for superseding old ones when newer are available, but not sure how eagerly it understands changes in (un)pinning versions et al. when it comes to just closing the old ones, esp. when there are conflicts pending to be resolved on its branches, better to do it manually FWIW…)

[janbrasna]

PS: can't tell whether that's related or not, but the build step now takes not 5-15mins as before, not 25-30 like here in the PR, but master and anything against master now builds in 55-60mins FYI…

(I would understand that if the PR did add "ruby" as a platform to compile the stuff instead of PCG, but it actually removes it so any impact here escapes me…)

It's the bundle update step https://app.circleci.com/pipelines/github/fastlane/docs/869/workflows/46b17f7a-2939-48e6-bcb2-ac61e5f45892/jobs/3403/parallel-runs/0/steps/0-105?invite=true#step-105-0_45 spending all the time "Fetching https://github.com/fastlane/fastlane...... Fetching gem metadata from https://rubygems.org/......... Resolving dependencies......." so it may be some networking woes, but I don't see any service disruption notices anywhere.

[janbrasna]

@revolter @rogerluan Anecdotally confirmed using various bundler versions, and extracting one bit from #1237 that did wonders TL;DR: I've opened #1249 that should fix this.