Skip to content

Request: restore Cargo.lock to the repository #134

Description

@Smona

Hey @efernau! Hope you're well.

I saw there were some comments on the commit, but I wanted to raise the removal of the Cargo lockfile in v1.0.1 as an actual issue.

We're trying to bump to the new release in nixpkgs, but as you can see we now have to generate our own lockfile to be able to package the new release. This has multiple negative consequences:

  • The behavior of the packaged application can very easily differ from how it was tested in the repo. This could lead to more bug reports in this repo as the versions hosted on various package repositories diverge.
  • More difficulty for contributors to this repo as they may be developing PRs with different package versions than will be tested by you or deployed in different package repos.
  • Additional work for packagers to keep the package up to date, increasing risk that new features will not be rolled out to end-users.
  • Risk of package builds that generate fresh lockfiles pulling in newly released vulnerable versions of dependencies, exposing users to security risk.

I'm sure you had a good reason to remove the lockfile so I may be missing something here, but I'm not aware of any downsides to tracking Cargo.lock. I see dependabot was absolutely spamming the repo, so maybe that was a motivation? But honestly, I think even a lockfile that doesn't receive updates for long periods of time is better than no lockfile. Given all the upsides to tracking it, I wanted to try to change your mind before we adapt to the removal.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions