dir2pi fails when normalized/non-normalized wheels are present about pip2pi HOT 3 CLOSED

Thanks! I’m a bit swamped right now, but I’d be happy to merge a PR that fixes this!

David

On Oct 14, 2015, at 11:34 AM, Seth Rosenblum [email protected] wrote:

When running dir2pi with symlinks and package normalization, dir2pi will fail if the same package is present with both a normalized and non-normalized package name. For instance, if I have these two wheels in a directory:

requests_oauthlib-0.4.2-py2.py3-none-any.whl # version from pypi
requests-oauthlib-0.4.2-py2.py3-none-any.whl # version created by pip2pi
running dir2pi will fail with an unhelpful error:

$ dir2pi --normalize-package-names wheelhouse
Traceback (most recent call last):
File "/usr/local/bin/dir2pi", line 11, in
sys.exit(dir2pi())
File "/usr/local/lib/python2.7/dist-packages/libpip2pi/commands.py", line 268, in dir2pi
return _dir2pi(option, argv)
File "/usr/local/lib/python2.7/dist-packages/libpip2pi/commands.py", line 305, in _dir2pi
os.symlink(symlink_source, symlink_target)
OSError: [Errno 17] File exists
This should probably just print a warning and skip.

—
Reply to this email directly or view it on GitHub #50.

phone: (416) 906-0403
pgp: B230230D

from pip2pi.

I'd love to see this merged. I just submitted my own PR that provides more verbose output that we've been using to track down this error when it crops up. Having an actual fix in place would be nice as well.

from pip2pi.

As a workaround, I found that using pip wheel --find-links $local_package_directory ... seems to skip duplicate packages, even if the filename has been normalized with dashes.

I also submitted a PR to just use the filename generated by pip wheel, which helps to lower the chances of ending up with conflicting packages.

from pip2pi.