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

[Feature] rocks sync command #273

Open
mrcjkb opened this issue Dec 22, 2024 · 2 comments
Open

[Feature] rocks sync command #273

mrcjkb opened this issue Dec 22, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@mrcjkb
Copy link
Member

mrcjkb commented Dec 22, 2024

  • Use the rocks.lock as the source of truth to sync rocks in a given tree.
  • Fail if there is no lockfile.
  • Fail if there are rockspec or source integrity mismatches
    • Should have an option to only warn on failed integrity checks (to handle force-uploaded scm rockspecs).
@mrcjkb mrcjkb added the enhancement New feature or request label Dec 22, 2024
@mrcjkb mrcjkb self-assigned this Dec 22, 2024
@mrcjkb
Copy link
Member Author

mrcjkb commented Dec 22, 2024

I think we should change hashes.source in the lockfile to an Option and only set it if the source in the rockspec is something that is unlikely to change (tag, although tags aren't always immutable, commit sha, non-scm URL, ...).
Perhaps we should never set it for dev versions. 🤔

@mrcjkb
Copy link
Member Author

mrcjkb commented Dec 31, 2024

To make sure rocks sync can be used by nixpkgs, we should not try to fetch the luarocks manifest. Instead, we should construct a RemotePackageDB from the lockfile.
This means we need to include the source URL for each RemotePackage in the lockfile.

🤔 Unfortunately, lockfiles that have binary rocks in them won't be cross-platform.

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

No branches or pull requests

1 participant