[20.03] python37Packages.starlette: 0.13 -> 0.12.9

[wd15]

Motivation for this change

• Revert Starlette to 0.12.9 as Fastapi requires that specific
  version of Starlette. Fastapi is Starlette's only dependent.

• Use fetchurl in place of fetchPypi as fetchurl gets all of the
  Starlette test suite, (fetchPypi fails to get any starlette tests)

This changes fixes Starlette fails and Fastapi fails

For ZHF: #80379

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • 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 nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[wd15]

Result of nix-review pr 81055 1

2 package were built:

• python37Packages.fastapi
• python37Packages.starlette

[rnhmjoj]

These packages are still broken master, why is this PR targeting relese-20.03?

[wd15]

These packages are still broken master, why is this PR targeting relese-20.03?

Should I fix on master and then cherry-pick to release-20.03? I'm not sure how to handle this.

I might need to find a better way to handle this then degrading the version number.

[wd15]

These packages are still broken master, why is this PR targeting relese-20.03?

Related question. Do changes on release-20.03 eventually get merged back into master?

[jonringer]

Related question. Do changes on release-20.03 eventually get merged back into master?

unidirectional. Changes are applied to master, then cherry-picked to release

When there's a enough divergence, it may be difficult to backport.

Unless the issue doesn't manifest in master, then there's no reason to do a commit to master first. But this is not the case with this PR.

[rnhmjoj]

Should I fix on master and then cherry-pick to release-20.03? I'm not sure how to handle this.

Yes, see the backport section of CONTRIBUTING.MD.

This PR is still good: we can just switch the target branch. There problem are your other two PR, which should have been made against master: #81041 #81043. I was really conviced they were backports; I should have been more careful.

I'm not sure what to do now, @jonringer is it acceptable to cherry-pick in the opposite direction just for this time?

[jonringer]

you can always do this from a branch:

git checkout -b master-XXX
git rebase --onto master HEAD^
git push .. ..

to go from the 20.03 branch, to master

[wd15]

Thank you both for explaining. I'll try and take care of this for the changes in #81041, #81043 and this one.

[wd15]

Closing this in favor of #81304 and #81305