Change:
Please see We have a lot of references to which we need to migrate to newer package(s) mentioned in the url above: * We also need some verify scripts to ensure we don't add back this package /area code-organization
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig architecture (seems like this cuts across everything!)
The package is deprecated but is not planned for removal. Switching is fine, but this is not urgent
mind if I take a look at this ? /assign
Ack !
For the script to verify the and ensure we don't add this back again, can I modify the existing toolchain to add a new field with similar behavior support as that of ?
ioutil is extremely widely used, and is not actually a problem to continue using... make sure the importverifier doesn't complain if we depend on it transitively via a vendored dependency
Sure. I will keep that in mind. I will enable this as a soft warning behavior if that is all right with everyone so that we can warn them but not fail the check right-away. Once we decide to enforce it, we can switch the config to fail the checks.
I'm skeptical that this is worth the effort to warn/sweep existing code
ack on the warn/verify we can deal with that later (i'll check on possibilities). let's focus this issue to just the bulk replace
Ack. Thanks
Most of the methods in ioutil have relatively simple implementations that seem stable, doubly so if it's deprecated If go isn't planning to remove this package any time soon I'm also not sure it's worth the cost of forcing library consumers to use go1.16+?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /priority important-longterm (based on Please feel to correct, if otherwise)
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /lifecycle frozen
looks like people are still submitting PRs on this topic and they are not getting reviewed. From Go perspective there's no update since the 1.16 announcement (AFAIK). Should we revisit this goal?
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Go compatibility means the deprecated functions will not be removed. I'm not in favor of this goal... I think it's churn with little purpose.
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
"bytes" "errors" "fmt" <del> "io/ioutil" </del> "os" "regexp"

regEndConformance := regexp.MustCompile(patternEndConformance) regSkip := regexp.MustCompile(patternSkip) <del> fileInput, err := ioutil.ReadFile(e2eFile) </del> <ins> fileInput, err := os.ReadFile(e2eFile) </ins> if err != nil { return fmt.Errorf("Failed to read file %s: %w", e2eFile, err) }

func processFile(e2ePath string) error { regGoFile := regexp.MustCompile(`.*.go`) <del> files, err := ioutil.ReadDir(e2ePath) </del> <ins> files, err := os.ReadDir(e2ePath) </ins> if err != nil { return fmt.Errorf("Failed to read dir %s: %w", e2ePath, err) }

} // Search sub directories if exist <del> files, err := ioutil.ReadDir(e2ePath) </del> <ins> files, err := os.ReadDir(e2ePath) </ins> if err != nil { return fmt.Errorf("Failed to read dir %s: %w", e2ePath, err) }