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

♻️ improve/outsource path model #34

Open
jeftadlvw opened this issue Jun 5, 2024 · 0 comments
Open

♻️ improve/outsource path model #34

jeftadlvw opened this issue Jun 5, 2024 · 0 comments
Labels
architecture-improvement Improves the overall architecture feature request New feature or request severity::okay This issue needs to be addressed within near time

Comments

@jeftadlvw
Copy link
Owner

jeftadlvw commented Jun 5, 2024

The Path model, originally intended as a simple and more accessible wrapper for golang's filepath, is widely used in the whole project for more specific (type) control. It's currently placed as a model and has no other any internal dependenies.

Recent issues and commits showed that this wrapper is not consistent enough and unpredictable in regarding to filesystem case-sensitivity. Because git-nest works on the filesystem level, it's highly important that filehandling is consistent and predictable, while also abstracting away filesystem-level case-sensivitiy.

Thus Path should be either rewritten and tested, or an external dependency.
Some libraries exist (https://github.com/spf13/afero, https://github.com/chigopher/pathlib), but these seem bigger than just simple lightweight wrappers (which is what's needed).

I don't mind if a Path becomes a little struct, but the footprint should be kept small. Maybe something like this is fitting:

type Path struct {
   path string
}

func NewPath(p string) Path {
   return Path{path: p}
}

func (p *Path) String() string {
   return p.path
}

// ... other functions

This keeps the footprint small, while also generating a source of truth (which is something the current "a path is really a string type" cannot give).

The new Path should also support windows and network paths, provide conversions, better error handling and byte/text marshaling/unmarshaling.

@jeftadlvw jeftadlvw added feature request New feature or request severity::okay This issue needs to be addressed within near time architecture-improvement Improves the overall architecture labels Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture-improvement Improves the overall architecture feature request New feature or request severity::okay This issue needs to be addressed within near time
Projects
None yet
Development

No branches or pull requests

1 participant