-
Notifications
You must be signed in to change notification settings - Fork 67
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
Add support for Windows #956
Add support for Windows #956
Conversation
8e593de
to
e76bc7c
Compare
2430bb0
to
859c27f
Compare
packages/fs.go
Outdated
@@ -35,23 +36,29 @@ func NewExtractedPackageFileSystem(p *Package) (*ExtractedPackageFileSystem, err | |||
} | |||
|
|||
func (fs *ExtractedPackageFileSystem) Stat(name string) (os.FileInfo, error) { | |||
return os.Stat(filepath.Join(fs.path, name)) | |||
return os.Stat(path.Join(fs.path, name)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that when accessing the file system directly, we should keep using filepath
, that takes into account the different separator in Windows. This would be for all methods of ExtractedPackageFileSystem
, that work on the native file system.
As a rule of thumb, if the path is used with a function of os
package, it should be manipulated with filepath
package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to work with path
, we could use os.DirFS
to build a fs.FS
.
Hi @jsoriano thanks for the tips, I'm on a learning curve so appreciate it! |
369aedf
to
e896116
Compare
Hey @jillguyonnet, I am thinking that it could be easier to fix the pending issues if we use
For that, we could create the
And we would make all operations with |
/test |
8d91a91
to
2a99b9d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job here, there were several tricky cases! Added some nitpicking.
I think the only thing I would like to see reviewed before merging would be to handle the error of WalkDir
, and to include the fsys.path
in error messages. For the rest it LGTM.
packages/datastream.go
Outdated
pipelineDir := filepath.Join(d.BasePath, "elasticsearch", DirIngestPipeline) | ||
paths, err := fs.Glob(filepath.Join(pipelineDir, "*")) | ||
pipelineDir := path.Join(d.BasePath, "elasticsearch", DirIngestPipeline) | ||
paths, err := fs.Glob(path.Join(pipelineDir, "*")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit. Maybe we should start using fsys
in general as abbreviation for filesystems to distingish from fs
package.
packages/fs.go
Outdated
} | ||
|
||
func (fsys *ExtractedPackageFileSystem) Glob(pattern string) (matches []string, err error) { | ||
fs.WalkDir(fsys.root, ".", func(p string, d fs.DirEntry, err error) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I recall correctly, WalkDir
returns an error, we should handle it.
@@ -28,32 +28,47 @@ type PackageFileSystem interface { | |||
// ExtractedPackageFileSystem provides utils to access files in an extracted package. | |||
type ExtractedPackageFileSystem struct { | |||
path string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the only reason to keep the path
now here would be to use it in error messages so users know to what package in the filesystem we are referring to. Use it when displaying paths in error messages of this package.
} | ||
for i := range matches { | ||
match, err := filepath.Rel(fs.path, matches[i]) | ||
pf, ok := f.(PackageFile) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment here mentioning that we expect this to be a plain os.File
, that implements this interface. It may look a bit random to convert to this interface otherwise.
packages/fs.go
Outdated
defer f.Close() | ||
return nil, fmt.Errorf("file does not implement PackageFile interface: %q", name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could think to even panic()
here, as all the files here should actually implement PackageFile
. But let's stay on the safer side and keep it as an error.
packages/fs.go
Outdated
defer f.Close() | ||
return nil, fmt.Errorf("file does not implement PackageFile interface: %q", name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a place where we may want to use fsys.path
to display the full path to the user. Something like this:
defer f.Close() | |
return nil, fmt.Errorf("file does not implement PackageFile interface: %q", name) | |
defer f.Close() | |
return nil, fmt.Errorf("file does not implement PackageFile interface: %q", filepath.Join(f.path, filepath.FromSlash(name))) |
If we do this on multiple places, you may consider to implement a helper method for that, something like this:
func (fsys *ExtractedPackageFileSystem) fullPath(name string) (string) {
return filepath.Join(f.path, filepath.FromSlash(name))
}
@jsoriano Thanks for the review, I addressed your comments. Very good point about func (fsys *ExtractedPackageFileSystem) Glob(pattern string) (matches []string, err error) and the only place I can see that might make use of fmt.Errorf("failed to obtain path under package root path (%s): %w", pattern, e) I suppose there could also be a custom error message in the Can you please let me know your thoughts on this and of anything else I might have missed? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job here!
Issue description
EPR currently fails to run on Windows due to the use of
filepath
library in an abstracted file system.What does this PR do?
Why is it important?
EPR currently cannot run on Windows.
Related issues