Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo: lock the dependencies #438

Open
RaitoBezarius opened this issue Oct 10, 2021 · 4 comments
Open

Cargo: lock the dependencies #438

RaitoBezarius opened this issue Oct 10, 2021 · 4 comments

Comments

@RaitoBezarius
Copy link

I am currently packaging symbolic in NixOS and we often need lock files to pin all dependencies, it seems like this repository do not have it which would require us to maintain the Cargo.lock ourselves, do you think it is possible to add it upstream?

Thank you for your work :)

@Swatinem
Copy link
Member

May I ask which part exactly you want to package?

In either case, I think one binary artifact that we ship is symbolic-cabi as part of the python package. Also for that usecase, I think its fair to add a lockfile. Let me run that by the team as well.

@flub
Copy link
Contributor

flub commented Oct 11, 2021

It doesn't really make sense for a library project to have a Cargo.lock file though, does it? it specifies the versions of our dependencies which it can handle and it is up to the binary using this to decide on the shape of their Cargo.lock file.

@RaitoBezarius
Copy link
Author

Agreed regarding locking the whole project, @flub
I was under the assumption that the symbolic-cabi is a binary, and it would be good to lock it, @Swatinem

If it does not make any sense, I can still lock it upstream, thanks !

@jan-auer
Copy link
Member

We used to have Cargo.lock checked in for the C-ABI binary. When we moved everything into a workspace, that was dropped. There's nothing wrong with bringing back Cargo.lock; however, we should ensure that it is regularly updated in CI so that we do not miss incompatibilities. If it's not a big deal to pin this upstream, that sounds like the best compromise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants