Allow for delocating top level modules.

[HexDecimal]

This delocates libraries into one directory per wheel. I've added a top-level package-less wheel to test with.

Prevents copying duplicate libraries when a wheel has multiple packages. Fixes #35.

Fixes issues where the module to work on is at the top-level, such as a wheel with no packages. Generally any current issue where delocate mysteriously doesn't bundle libraries has been fixed. Fixes #72, fixes #22, fixes #45, fixes #63, fixes #121, fixes #66, fixes #49, fixes #67.

See _decide_dylib_bundle_directory for how the folder to use is determined. I've followed the advice from #72 to use an auditwheel-style name. Wheels without packages use the folder {package_name}.dylibs, wheels with packages will put a .dylibs folder in only one of the packages preferring the one that matches the wheel name. The one directory will hold the dependencies of the entire wheel.

After that the fix was simple: In delocate_wheel call delocate_path only once and call it with a tree_path that includes the entire wheel.

Since this always collects everything regardless of if a package is found or not. This will also resolve issues where namespace packages couldn't be delocated. Fixes #95.

[codecov-commenter]

Codecov Report

Merging #123 (bea78a7) into master (9038521) will increase coverage by 0.11%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #123      +/-   ##
==========================================
+ Coverage   94.76%   94.88%   +0.11%     
==========================================
  Files          13       13              
  Lines         994      997       +3     
==========================================
+ Hits          942      946       +4     
+ Misses         52       51       -1     

Impacted Files	Coverage Δ
delocate/delocating.py	97.60% <100.00%> (+0.50%)	⬆️
delocate/tools.py	93.98% <100.00%> (+0.02%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9038521...bea78a7. Read the comment docs.

[matthew-brett]

Fantastic - thanks! Just a few suggestions. Are you testing the case for more than one package in wheel?

[matthew-brett]

How about a test for namespace packages as well? (Sorry for the stream of requests).

[HexDecimal]

Are you testing the case for more than one package in wheel?
How about a test for namespace packages as well?

Only the current wheels are tested so more wheels either need to be added or the current need to be modified to be more diverse. There are no wheels using namespace packages, or wheels with more than one package.

Namespace packages are currently treated the same as wheels with no packages. I see this as acceptable since wheel names shouldn't collide.

While there are no wheels with multiple packages, both the conditions of selecting a package by the wheel name and selecting a package alphabetically have been covered by tests.

[HexDecimal]

I've added a namespace wheel with a typical test for it.

[matthew-brett]

Just a final few comments.

[matthew-brett]

Thanks very much for this - it's a big step forward.

[HexDecimal]

I'd like to make a release of a version with this merged. make_release.rst mentions making announcements to a mailing list, but I don't see the mailing list this is referring to. If you ever want to make a release then all you have to do right now is push a tag with the version (after following the release guide of course.)

We should also look at the other PR's which were trying to implement this feature: #36 #38 #39 #74 can probably be closed without merging. #96 might improve the handling of namespace packages but I don't think the author will care much now that namespace packages decloate correctly.

[matthew-brett]

Yes, good idea to make a release. Maybe this could be version 1.0, to signal the loss of Python 2, and the extended features. We could leave up #96 for now, and let the author decide later ...

[HexDecimal]

I'm not sure about a 1.0 release yet. Semantic versioning gives more flexibility for public API changes before a 1.0.0 release and I'm not sure the API is settled yet.

[matthew-brett]

I have personally found little use for applying semantic versioning with any rigor. Basically, it seems to me that we always want to preserve the API, or migrate sensibly, and a version number change will do little to effectively warn users that a breaking API change is on the way. But if you'd rather play it that way, that's OK too.

[HexDecimal]

I'm not sure. It's probably not as big of a deal to have a stable programming API for a primarily CLI tool, but my current suggestion is to go with 0.10.0 as the next version.

[matthew-brett]

That's fine too - it's really not a big deal - I don't think people pay much attention to version numbers anyway.

[HexDecimal]

Semantic versioning just sets the rules for why versions are what they are. If you released 1.0.0 and then break the API right away then the next version will be 2.0.0 and it isn't really a big deal for that to happen as long as the versions are set correctly.

1.0.0 is used to express confidence that the current API is stable and that more care will be taken to keep compatibility with it. I wouldn't use it to mean anything else. With how careful you've been treating breaking cases you probably could've been using 1.0.0 a long time ago.

Personally, there are things I'd like to do or braking changes I'd consider making before 1.0.0. I'd rather not release that version before everything is type-hinted for example.

[asottile]

can confirm this works -- thanks for picking up this patch!