File flake input broken in latest git version

[yshui]

Steps To Reproduce

Use this flake input:

  inputs.rust-manifest = {
    flake = false;
    url = "https://static.rust-lang.org/dist/2024-02-04/channel-rust-nightly.toml";
  };

I get this error when trying to run nix flake update:

error:
       … while updating the lock file of flake 'git+file:///......'

       … while updating the flake input 'rust-manifest'

       … while fetching the input 'https://static.rust-lang.org/dist/2024-02-04/channel-rust-nightly.toml'

       error: opening directory '/nix/store/cwisimrkdp10f14yichyzh34f85h8qdk-source': Not a directory

Priorities

Add 👍 to issues you find important.

[yshui]

This is also inconsistent. If I use a git input, nix flake update fails, but it succeeds for path input path:/path/to/flake.

[yshui]

And in addition to that, with a path input, the generated flake.lock is unusable:

error:
       … while updating the lock file of flake 'path:/path/to/flake?lastModified=1708909146&narHash=....'

       error: input attribute 'treeHash' not supported by scheme 'github'

[NobbZ]

As this currently blocks me, I did a "quick" bisection finding b36857a as the first bad commit for the treeHash at least:

b36857ac8d60cbf9a78c3c69f6370d38a14facbc is the first bad commit
commit b36857ac8d60cbf9a78c3c69f6370d38a14facbc
Author: Eelco Dolstra <edolstra@gmail.com>
Date:   Wed Nov 29 12:35:08 2023 +0100

    Add a Git-based content-addressed tarball cache

    GitArchiveInputScheme now streams tarballs into a Git repository. This
    deduplicates data a lot, e.g. when you're fetching different revisions
    of the Nixpkgs repo. It also warns if the tree hash returned by GitHub
    doesn't match the tree hash of the imported tarball.

 src/libfetchers/attrs.cc     |   5 ++
 src/libfetchers/attrs.hh     |   2 +
 src/libfetchers/git-utils.cc | 178 +++++++++++++++++++++++++++++++++++++++++++
 src/libfetchers/git-utils.hh |  10 +++
 src/libfetchers/github.cc    | 114 ++++++++++++++++++---------
 5 files changed, 272 insertions(+), 37 deletions(-)

[edolstra]

I can't reproduce this. It may have been fixed by 930b9c8 and/or 9ee590e.

[brprice]

I also stumbled across this, and found

• first bad commit b36857a
• fixed by 071dd2b

the mentioned commits form the following ancestry

   9ee590
    |    \
 071dd2  930b9c
    |    /
   b36857