Change:
{ lib <del> , fetchFromGitHub </del> <ins> , fetchzip </ins> , rustPlatform , stdenv , darwin }: <del> with rustPlatform; buildRustPackage rec { version = "0.22.0"; </del> <ins> rustPlatform.buildRustPackage { version = "0.26.0"; </ins> pname = "geckodriver"; <ins> sourceRoot = "source/testing/geckodriver"; </ins> <del> src = fetchFromGitHub { owner = "mozilla"; repo = "geckodriver"; rev = "v${version}"; sha256 = "12m95lfqwdxs2m5kjh3yrpm9w2li5m8n3fw46a2nkxyfw6c94l4b"; }; </del> <ins> # Source revisions are noted alongside the binary releases: # https://github.com/mozilla/geckodriver/releases src = (fetchzip { url = "https://hg.mozilla.org/mozilla-central/archive/e9783a644016aa9b317887076618425586730d73.zip/testing"; sha256 = "0m86hqyq1jrr49jkc8mnlmx4bdq281hyxhcrrzacyv20nlqwvd8v"; }).overrideAttrs (_: { # normally guessed by the url's file extension, force it to unpack properly unpackCmd = "unzip $curSrc"; }); </ins> <del> buildInputs = lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.Security ]; </del> <ins> cargoPatches = [ ./cargo-lock.patch ]; cargoSha256 = "07w5lmvm5w6id0qikcs968n0c69bb6fav63l66bskxcjva67d6dy"; </ins> <del> cargoSha256 = "1pwg35kgn5z2zrlj1dwcbbdmkgmnvfxpxv4klzsxxg4m9xr1pfy4"; </del> <ins> buildInputs = lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.Security ]; </ins> meta = with lib; { description = "Proxy for using W3C WebDriver-compatible clients to interact with Gecko-based browsers";

Discussion:
geckodriver is currently stuck at 0.22 because the packaging changed to remove the file. The recommended way to get the source now is to checkout the mozilla-central megarepo and build the testing/geckodriver folder. It doesn't seem like a good idea to clone the whole mozilla megarepo to get the source so perhaps the only way to unstick this issue is to package the binary instead. See for some discussion about this already. Any opinion ?
IMO upstream should try to be more source-based downstream friendly, but I don't see how that mine opinion helps us here in any way. :stuckouttongueclosedeyes: Is that the only feasible way? Packaging binaries when the source code is available always feels kinda icky to me. Could we e.g. fetch just the relevant information from the mega-repo (Is that only the file, or is there more to it?) and use it to check out the right revision of the geckodriver repo?
Btw., should upstream issue be re-opened (or, probably better, re-filed with the current versions) or is it already foreseeable that "just use the mega-repo and " would be the answer to the question asked there?
I just checked again and the "source" from the github release doesn't actually contain the source code for but just the files from the repo. So I don't know of a way of getting the source without cloning the megarepo. I stumbled across this blog post where the problem of cloning mozilla-central is discussed - The mozilla megarepo is about 40gb to clone so that isn't an option and because mercurial doesn't support shallow clones, it seems the only option left is to package the binary.
The Arch maintainers just don't even bother with the "lock file".
There is an alternative which builds from the mercurial repo -
Note there is also a mozilla-central mirror on GitHub: Unfortunately, which would be the most realistic real solution does not work with remote Mercurial repositorues.
It doesn't appear that there is a file in the github mirror, or upstream either. So even if we somehow manage to get the source, we won't be able to use the rust builder to build it without creating our own ?

I looked at how homebrew got the source for geckodriver and it seems you can just download some of the subfolders. So I tried to package it but got stuck because apparently the lock file is not synced up with the file. If anyone wants to try to finish this then I have pushed my WIP branch here: I am going to see how easy it is to package the binary.
how about just generating one lock file and adding it as a patch ? Random example: Pro: every other solution seems so painful Con: cargo must manually be run on the source by the maintainer on each update to get a new file.
… which might be scriptable. And maybe some updates would even tolerate an older
Pinging who's of the derivation.
I didn't know how to generate a lock file and given packaging the binary was so simple I stopped trying to build from source.
To generate a lock file: 1/ clone the source 2/ run cargo check Even if it fails to compile, it will create a lock file.
: Nothing much to contribute / add here, if anyone want to jump in as maintainer, this is fine by me. Added this package as a dependency to selenium for some client side testing I had to support for some project. I no longer use the package and when I first it, it was pretty much the monkey see monkey do way (never had the opportunity to dabble with rust and its package manager). It looks however like a good thing to keep in nixpkgs either built from source or using the prebuilt binary.
is the command to just generate a lockfile and do nothing else.