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.

Sign up for GitHub

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

Jump to bottom

Add ability to ignore packages #35

Open
mandre opened this issue Sep 11, 2023 · 4 comments · May be fixed by #36
Open

Add ability to ignore packages #35

mandre opened this issue Sep 11, 2023 · 4 comments · May be fixed by #36

Comments

@mandre
Copy link

mandre commented Sep 11, 2023

It could be useful to allow user to specify a list of packages to ignore when checking for API compatibility, when one does not care about a subset of packages such as tests.
mandre added a commit to mandre/go-apidiff that referenced this issue Sep 11, 2023
@mandre
Add ability to ignore packages
388242f 
By passing the `--ignore` flag to go-apidiff it is now possible to
ignore incompatible changes in a list of packages. This flag can be
specified multiple times.

This is passed via the `ignore-list` input parameter in the github
action and must be specified as a comma-separated list.

Fixes joelanford#35
@mandre mandre linked a pull request Sep 11, 2023 that will close this issue
Open
@joelanford
Copy link
Owner

I'm not sure this is something we should support or encourage (see #14 (comment)).

I would recommend moving test utilities to an internal tree if you do not want users of your library to use them.

@mandre
Copy link
Author

mandre commented Sep 12, 2023

I understand that the internal directory is a go convention and moving files around would solve the issue for us, however not everyone wants to adopt this convention which causes users to implement workarounds like kubernetes-sigs/cluster-api-provider-azure#2567.

From my point of view, it's still useful to allow users to ignore specific paths.

@joelanford
Copy link
Owner

I understand that the internal directory is a go convention

It is more than a convention. Dave Cheney has a succinct blog post about it here: https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface

TL;DR: internal packages are enforced to be internal by the go compiler. Conversely, non-internal packages are external and can be imported by your users.

As such, any breaking change in a non-internal package is, by definition, a breaking change to the API surface of the go module.

The goal of go-apidiff is to report on whether a change could have the potential to break any importers of the changed packages.

not everyone wants to adopt this convention

What is holding folks back from adopting use of internal trees for non-public APIs?

@EmilienM
Copy link
Contributor

@joelanford what about this use case: kubernetes-sigs/cluster-api-provider-openstack#2096

v1beta1 package is stable, but not v1alpha1. I still want to run apidiff against v1beta1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add ability to ignore packages mandre/go-apidiff
3 participants
@mandre @joelanford @EmilienM