python3Packages.email-validator: 2.1.0 -> 2.1.1

[endgame]

Description of changes

https://github.com/JoshData/python-email-validator/releases/tag/v2.1.1

Upstream reissued their 2.1.0 tarball, breaking non-cache fetches. May as well move to the new release.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[jcfj]

Upstream reissued their 2.1.0 tarball

If upstream is known to do these things (I seems that also happened to 2.0.0), wouldn't it be better to reference the release by commit instead of by tag? (This is not a rhetoric question. I'm somewhat new to nix and really asking.)

For reference:

• 2.1.1 currently points to 676e0ab8def3cbee6fc212ad66cd55c22a66df41
• Upstream changes to 2.1.0:

  diff -Naur archived/email_validator/version.py python-email-validator-2.1.0/email_validator/version.py
  --- archived/email_validator/version.py	2024-02-29 15:02:17.132118331 +0900
  +++ python-email-validator-2.1.0/email_validator/version.py	2023-10-23 19:04:32.000000000 +0900
  @@ -1 +1 @@
  -__version__ = "2.1.0"
  +__version__ = "2.1.0.post1"
  diff -Naur archived/setup.cfg python-email-validator-2.1.0/setup.cfg
  --- archived/setup.cfg	2024-02-29 15:02:17.132118331 +0900
  +++ python-email-validator-2.1.0/setup.cfg	2023-10-23 19:04:32.000000000 +0900
  @@ -27,7 +27,7 @@
   install_requires =
       dnspython>=2.0.0 # optional if deliverability check isn't needed
       idna>=2.0.0
  -python_requires = >=3.7
  +python_requires = >=3.8
   
   [options.package_data]
   * = py.typed

  resulting in

  error: hash mismatch in fixed-output derivation '/nix/store/793322din6hg2lxzf4ns5xqkh818l79a-source.drv':
           specified: sha256-58DuQslADM7glrnlSSP6TtIDTlwuS0/GK8+izatqDxI=
              got:    sha256-gL2I5MfBNqDR4IWg5KJ8OV0j4XfeV0QHNXMtaAkfB+Q=
  

[endgame]

I don't know either, and I'm not sure what nixpkgs' best practice is. I was just testing some "what can I build without substituters?" and decided to drive-by a fix.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-in-distress/3604/91

[doronbehar]

Note there are a lot of rebuilds, this PR should target staging.

[pbsds]

What’s the best way to deal with an upstream which reissues tarballs that have different hashes?

Commonly we use archive.org for hash-unstable urls. If the new tarballs include security fixes, then they could be added in follow-up PRs

[endgame]

Closing in favour of #293715 so I don't ping a zillion people by fiddling with branches.