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

Bug when using CLibrary() on a Windows Path #42

Open
LeoSebal opened this issue Jun 10, 2020 · 3 comments
Open

Bug when using CLibrary() on a Windows Path #42

LeoSebal opened this issue Jun 10, 2020 · 3 comments

Comments

@LeoSebal
Copy link

Hi Matthieu,

Thank you for this fantastic module. I think it made a task I had to do something in the lines of 4 times faster. Unfortunately, as thankful as I am for this module, I'm not here for that, but to report a bug.

I have noticed that, when using the function CLibrary on Windows, pyclibrary only manages to locate the DLL in a different folder than the cwd if the path provided is a string with only backward slashes (Windows style). I have tried many variations: string with a forward slash, many variations of the libpath.Path and the libpath.PurePath submodules, with no success. I ended up using libpath.Path and convert it to a string with the as_posix() argument, then replacing the forward slashes with backward slashes if we're on Windows... Which kinda works but, as you guess, is not clean.

Anyway, I would like to thank you again for this fantastic work. Let me know if you need any additional information.

@MatthieuDartiailh
Copy link
Owner

The code handling the library loading is here https://github.com/MatthieuDartiailh/pyclibrary/blob/master/pyclibrary/c_library.py#L60
Since we allow to simply path the library name without a full path we need a way to discriminate between name and path and currently the logic relies on the presence of os.sep which indeed means that on Windows you need a Windows formatted path.

You could as a workaround use os.path.join that will create an OS specific path from a variable number of parts. That way your code does not make assumption about the OS and the expected format of the path.

@LeoSebal
Copy link
Author

Thank you for your answer! Indeed, I am now using os.path.join() instead of pathlib's paths, and it works perfectly. Specifically:

CLibrary(os.path.join(*clib_path.parts), parser)

where clib_path is a pathlib.Path object. Its attribute parts returns the components of the path as a list.

Out of curiosity, are you familiar with the pathlib module? I learned recently that it takes care of all that kind of headache with a lot of flexibility, and quickly became my go-to module for file management.

@MatthieuDartiailh
Copy link
Owner

I do know about pathlib but never used it. I am usually happy with os.path. I guess we could support path-like object, is it something you could contribute ?

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

No branches or pull requests

2 participants