Open jtniehof opened 2 years ago
There may be scope for considering the path handling, too. Does it make sense to say that the database is always Unix paths, or do we say it's always native paths and then provide a means of migrating? I'm worried about people putting path separator characters in filenames, for instance (it's hard to do, but maybe possible in some cases, and certainly possible to put path separators for Windows into a Unix filename.)
EDIT: Note that we do some patch matching by regular expression, so need to make sure regex escape \
is distinct from path-separator \
.
I'm starting on Windows support (just getting the unit tests going) and running into the fact that our test databases are Unix. It's not all bad, since we sort of decided the pathing was going to be Posix and a lot of the code automatically translates it to Windows pathing. But there's no handling of drive letters. I think we're probably just getting the current drive as an assumption, which maybe isn't bad, but probably should make sure that directories specified as absolute paths can have drives specified.
Alternatives
Not having Windows support, or always assuming everything is on the current drive, neither of which is deeply appealing.
OS, Python version, and dependency version information:
Version of dbprocessing
Current github master (fb95a08ff01bf293a4a4059f331ad4860066ddb7)
Closure condition
Close when the handling (and specification) of drive letters is documented and tested. Implementation should be not too complicated.