search

mohanson / gameboy

Full featured Cross-platform GameBoy emulator by Rust. Forever boys!.
MIT License
1.36k stars 79 forks source link

Please add Cargo.lock to .gitignore #17

Closed eduardossampaio closed 4 years ago

eduardossampaio commented 4 years ago

Cargo.lock is a generated file by cargo, but build fail if your generated Cargo.lock is present. Suggestion: delete Cargo.lock and add it to .gitignore

mohanson commented 4 years ago

The development spec I understand is that bin needs check-in Cargo.lock, See:

https://github.com/rust-lang/cargo/issues/315#issuecomment-51075730

eduardossampaio commented 4 years ago

That is correct, but Cargo.lock is a generated file by build at first time. I'm suggesting to ignore it because build fails after I clone the project. The error disapeared after I delete the Cargo.lock file.

after removing cargolock error Cargolock after git clone
ethanpailes commented 4 years ago

@eduardossampaio The typical pattern with cargo files is to check in Cargo.toml for libraries and checkin in both Cargo.toml and Cargo.lock for applications. Cargo.toml expresses the constraints you believe to describe the deps that work with the project which is good when you have a unknown number of consumers using your packages with their own dep constraints, while Cargo.lock describes a list of actual deps which is good when you want stability. Applications don't have any downstream consumers, so Cargo.lock should be checked in.

If deleting Cargo.lock fixed the build for you, your compiler version might be out of date with the project or there could just be a bug in the Cargo.lock file that needs to be fixed. Perhaps you could post the diff between the Cargo.lock that gets generated after you blow away the old one and the one that is checked in. That might show the issue.

namibj commented 4 years ago

That is correct, but Cargo.lock is a generated file by build at first time. I'm suggesting to ignore it because build fails after I clone the project. The error disapeared after I delete the Cargo.lock file.

The problem is, that there is zero guarantee that cargo will be able to generate a working Cargo.lock file in the future. This is very pronounced with pre-1.0 crates and git-branch-references, as both aren't claiming any stability via SemVer.

yazgoo commented 4 years ago

As mentioned by @ethanpailes, Cargo.lock should be kept, I think this issue can be closed (my 2 cts :) )