zed

zed copied to clipboard

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

I am consistently getting build errors when I try to carry out a cargo build on a freshly git-cloned zed repo.

For example...

~/Code/rust/zed  cargo build
    Updating crates.io index
    Updating git repository `https://github.com/zed-industries/wezterm`
warning: spurious network error (3 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34)
warning: spurious network error (2 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34)
warning: spurious network error (1 tries remaining): http parser error: stream ended at an unexpected time; class=Http (34)
error: failed to get `procinfo` as a dependency of package `terminal v0.1.0 (/Users/carlcaulkett/Code/Rust/zed/crates/terminal)`

Caused by:
  failed to load source for dependency `procinfo`

Caused by:
  Unable to update https://github.com/zed-industries/wezterm?rev=5cd757e5f2eb039ed0c6bb6512223e69d5efc64d#5cd757e5

Caused by:
  failed to fetch into: /Users/carlcaulkett/.cargo/git/db/wezterm-594d071f81851ec6

Caused by:
  network failure seems to have happened
  if a proxy or similar is necessary `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  http parser error: stream ended at an unexpected time; class=Http (34)

[101 - ][Thu Feb 01 2024  9:54pm (GMT+0000)]  (main)  via 🦀 v1.75.0  took 9m43s

This seems to point to connection problems, but while it's true I do not have a very good internet connection, I have never had any problems carrying out cargo builds on repos with many dependencies...

Environment

Zed: v0.121.1 (Zed Preview) OS: macOS 13.6.0 Memory: 16 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.

No response

TL;DR: In my case the wifi was borked and using a different network fixed it. Original reply below.

---

Same issue here and oddly, even with

cargo build --release --keep-going --config net.git-fetch-with-cli=true

I'm eventually getting

remote: Enumerating objects: 108474, done.
remote: Counting objects: 100% (11701/11701), done.
remote: Compressing objects: 100% (411/411), done.
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)
error: 52150 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
error: failed to get `procinfo` as a dependency of package `terminal v0.1.0 (/home/mmayer/dev/foreign/zed-industries/zed/crates/terminal)`

Caused by:
  failed to load source for dependency `procinfo`

Caused by:
  Unable to update https://github.com/zed-industries/wezterm?rev=0c13436f4fa8b126f46dd4a20106419b41666897#0c13436f

Caused by:
  failed to update submodule `freetype/libpng`

Caused by:
  failed to fetch submodule `freetype/libpng` from https://github.com/glennrp/libpng.git

Caused by:
  process didn't exit successfully: `git fetch --tags --force --update-head-ok 'https://github.com/glennrp/libpng.git' '+refs/heads/*:refs/remotes/origin/*' '+HEAD:refs/remotes/origin/HEAD'` (exit status: 128)

I'm unsure what exactly we can do here, since it seems like it depends on your network connection. What did you have in mind?

Thanks for the reply! I was actually able to finally build Zed by downloading (not git cloning) a couple of the dependencies (tree-sitter-haskell and tiktoken-rs) and tweaking the cargo.toml to suit. Interestingly both the git clone command and the cargo build command seem to have a three-strikes-and-you're-out policy, so if the connection is sufficiently crap, like mine is, getting a complete build is very difficult. The two dependencies I mentioned appear to be particularly bulky!

Yeah. I think wezterm is big, seems like we only want a small part of it.

I'm going to close this, since I don't think we can do anything besides using less dependencies but we're working on that with extensions anyway (will remove a lot of submodules).

Somewhat related #8604