kio.LocalPackageReadWriter should provide file system abstraction

[campoy]

Is your feature request related to a problem? Please describe.

Testing any program using kio.LocalPackageReadWriter, kio.LocalPackageReader, or kio.LocalPackageWriter is quite cumbersome due to its lack of abstraction allowing to fake the file system it reads from. This leads to very complex test cases where temp directories need to be created and destroyed continuously.

Describe the solution you'd like

I would like these types to include a FileSystem field in they would use in order to interact with the file system. By default, this would be set to interact with the actual file system so the change would be backwards compatible.

Describe alternatives you've considered

There are other packages providing a similar file system abstraction that we could consider.

• sigs.k8s.io/kustomize/pkg/fs also provides a FileSystem interface that seems to be very similar, I'm not sure which one we should be using or whether this one in the one mentioned above should be unified eventually.

• Go 1.16 comes with an fs package but this would force kustomize and all its users to update to Go 1.16, which seems a non-starter.

If this issue is accepted, I would like to provide a PR I have already been working on.

[KnVerey]

/triage accepted
/assign @campoy

[monopole]

Thanks!

Just to add some history, the impls of https://pkg.go.dev/sigs.k8s.io/kustomize/api/filesys#FileSystem are both in that package (same package as the ifc). The main ctors one would use at injection points are

• MakeFsOnDisk (for the kustomize CLI and tests that must have a disk file (e.g. plugin compiler tests)).
• MakeFsInMemory (for the vast majority of tests, e.g. harness use).

The goal was to just meet kustomize's IO needs, so no chmod, chown, seeking, truncating, etc.

Despite being in the same package, I think the two impls are independent. We could move them into subpackages to make that easier to prove, but it hasn't come up.

[k8s-triage-robot]

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, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[KnVerey]

/remove-lifecycle stale

The PRs implementing this are all complete; only one left to merge.

[k8s-triage-robot]

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, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[KnVerey]

/close

The implementation merged a while ago

[k8s-ci-robot]

@KnVerey: Closing this issue.

In response to this:

/close

The implementation merged a while ago

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.