chore(dep-resolution): update dep-resolution RPC interface to support lockfiles #312
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Backwards compatibility summary: |
|
@aryx @nmote I have these changes I want to make to the RPC interface. They aren't backwards compatible, so the check fails. As far as I can tell, though, there is no real need for backwards compatibility in these RPC types (if ATD had a module system so that we could use types from Can we ignore the backwards compatibility check here? Or should I restructure these changes to be backwards compatible? (I think the latter would probably look something like adding a new RPC call |
|
yes we can ignore the backward check. @mjambon is there a way to adjust the linting to give a list of toplevel type that don't need to go throught the backward compatibility check? (basically the RPC stuff and the semgrep-core output). |
aryx
approved these changes
Nov 8, 2024
gautambhat
reviewed
Nov 8, 2024
2 tasks
bkettle
force-pushed
the
bk/ddr/refactor-rpc-interface-for-lockfiles
branch
from
dc8a4a6 to
c78ebe8
Compare
|
@aryx I'm finally ready to merge this and the accompanying There's no reason this needs to be in this week's release, so we should probably wait until after. |
|
Yes I can override the backward compatibility check because I'm admin on this repo I think. @mjambon too. |
|
@mjambon we need to be able to whitelist a few entry types to not be concerned by the backward compatibility check (e.g., the types for semgrep-core or here the types for Nat's RPC, or we need a module system so we can use |
|
The whitelist seems the easiest option. |
|
Thanks @aryx ! Agree that a whitelist seems nice; it would be good to be able to make changes to the RPC interfaces more easily. |
|
yes, and merging the semgrep-interface inside the semgrep-pro repo would accelerate things even more. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updates the RPC interface used to resolve dependencies in OCaml to support
lockfiles as well as manifests. This will allow us to begin porting lockfile
parsers to Ocaml as we move forward.
These changes also make it possible to report errors that do not cause dependency resolution to fail entirely.
These changes are not backwards compatible. However, they only affect types
that are used within the CLI, from the Python code to the OCaml code, so as long
as we are careful with releasing the changes to the CLI, it should be safe.
make setup && maketo update the generated code after editing a.atdfile (TODO: have a CI check)For example, the Semgrep backend need to still be able to consume data generated
by Semgrep 1.17.0.
See https://atd.readthedocs.io/en/latest/atdgen-tutorial.html#smooth-protocol-upgrades
This must be merged in sync with https://github.com/semgrep/semgrep-proprietary/pull/2571 since it has breaking changes.