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

Question: Relation to io/fs? #11

Closed
nmeum opened this issue Dec 29, 2020 · 8 comments · Fixed by #81
Closed

Question: Relation to io/fs? #11

nmeum opened this issue Dec 29, 2020 · 8 comments · Fixed by #81

Comments

@nmeum
Copy link

nmeum commented Dec 29, 2020

How does this library relate to the io/fs draft which has been accepted recently and will be a part of go 1.16, which is scheduled to be released in February? How will this affect go-git and will go-git migrate to io/fs?

@happybeing
Copy link

Just reading the abstract, the io/fs draft says it is for read-only filetrees so it wouldn't be suitable replacement for go-git's go-billy filesystem. So maybe that isn't what you are asking - of not can you clarify?

@nmeum
Copy link
Author

nmeum commented Dec 29, 2020

My understanding is that support for writeable files is supposed to be added later on:

It's true that if we later want to add writing, […]

It should also be possible to employ the extension pattern to implement write-related functionality on top of fs.FS in the meantime [1]:

Although the initial interface is limited to read-only file systems, the design can be extended to support write operations later, even from third-party packages.

@happybeing
Copy link

Reading the issue comment (your "supposed..." link), it doesn't sound like there's an intention to support writing yet, but to put it off and maybe not do it at all. Yes, he acknowledges it could be added later, but it doesn't seem to be in the mind of the poster to do that. Read the last line.

So I think your question is moot for now, but I'm not replying in behalf of the maintainers. I was curious about the possibility because I've been using go-billy recently and think it would be useful to have that kind of flexibility in io/fs.

Do you have a reason to want this convergence?

@nmeum
Copy link
Author

nmeum commented Dec 29, 2020

So I think your question is moot for now, […]

As I said: One can use the extension pattern to implement missing functionality.

Do you have a reason to want this convergence?

Yes, io/fs is much closer integrated with the standard library. For example, you can simply pass an fs.FS to a http.FileServer many other functions from the standard library have also been adjusted accordingly. The draft further explains the advantages of this approach, please consult it if you seek more information.

@luisdavim
Copy link

Something like https://github.com/forensicanalysis/gitfs to make them compatible would be nice to have out-of-the-box.

@evankanderson
Copy link
Contributor

Would a PR to add billy.AsFS(billy.Filesystem) fs.FS (or some larger union type that included fs.FS, fs.ReadDirFS, fs.StatFS, etc) be accepted? I have an implementation I wrote to enable some integration with another library which is using io/fs.

@pjbgf
Copy link
Member

pjbgf commented Sep 12, 2024

Hey @evankanderson, I would be happy to review the PR and discuss it further. Just as a thought, this could potentially be a new package in helper that augments a billy.Filesystem with the io/fs interface, like we already do with helper/chroot.

@evankanderson
Copy link
Contributor

Awesome! I discovered that the Go standard library has a test suite for fs.FS implementations already, so I mostly just re-used that (except that fs.FS is read-only at the moment, which may be a blocker for adoption by go-git).

I also couldn't find a CONTRIBUTING.md or the like in this repo, so I just took a best-guess.

@pjbgf pjbgf closed this as completed in #81 Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants
@luisdavim @happybeing @nmeum @pjbgf @evankanderson and others