Commiting the Cargo.lock

[happysalada]

Hi, could you commit the cargo.lock file please ?

The reason I am asking is that it is usually needed to build the software from source to package for other discributions.
I am currently having a look at packaging for nixos.

Let me know if you need more details.

[houqp]

The general rule of thumb is to only checkin lock files for crates that produces binary artifacts. For example: datafusion-cli, ballista-scheduler, ballista-executor, etc. But we should avoid checking in lock file for the datafusion core itself since it's a library.

[happysalada]

Right, I completely agree. I wanted to try out datafution-cli . Do you think you can commit the lockfile for it ?

[houqp]

adding a lockfile to datafusion-cli should be fine, you can generate one by running cargo build locally, then send a PR to have it checked it :)

[happysalada]

happy to do an MR!
One more question though. Would you prefer a cargo lock in the datafusion-cli directory only for that project, or a global cargo.lock that would be added to the cargoignore. With the second way, everyone who develops on the repo would benefit from it.
Let me know what you prefer.

[houqp]

Thank you. Please put the lock file only in datafusion-cli folder so it won't get applied to the datafusion core library :)

[happysalada]

like I said in the PR. unfortunately cargo does not tolerate a lock that is not at the root of the workspace.
So as a workaround I added exclude statements in the other cargo.toml files (for all the libraries).
Let me know.

[happysalada]

Sorry, just have a follow up PR. By the time the first PR was merged, the lock had drifted
#2178