You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could you provide a little more information about how you're using it, and what is incorrect? I suspect you're reading Distribution.packages and seeing ["find:"] which is what the project gave. If you're interested in the more interpreted version of that value, you probably want Distribution.packages_dict or Distribution.source_mapping. (Note: 0.8.0 doesn't print source_mapping from the cli, but 0.9.0b2 or main does.)
The "version mismatch" problem we've noted internally comes from something similar, being tracked in #4 -- depending on your application for the data, you might want to know that it's being read from a file, and if so which file, or you might just want the numeric result.
Related, dowsing currently doesn't emulate anything related to package_data (because it's complex, easy to get wrong, and it's far safer to just include everything under a top-level dir). See comment at https://github.com/python-packaging/dowsing/blob/main/dowsing/types.py#L113 (and your py.wtf might be the "some people" it refers to).
See #70 for an overview of where I'd like to spend my time.
I'm mostly lacking test cases for the IDIC of setuptools-isms. If you have more, please send them my way! I've done a near-full analysis of pypi a couple of years ago focused on buildability from source, and may well do another on dowsing accuracy next chance I have good internet.
I also think it would be interesting to produce a package_dir and top-level mapping for all projects as a static json file you could just grab. I was able to fill in some gaps in static extraction by building in a well-stocked VM that has numpy, cffi, etc preinstalled in my last experiment. My various projects are increasinly interdependent (dowsing started out from a need in opine and checkdeps only knows about already-installed projects).
Activity
thatch commentedon Sep 3, 2022
Could you provide a little more information about how you're using it, and what is incorrect? I suspect you're reading
Distribution.packagesand seeing["find:"]which is what the project gave. If you're interested in the more interpreted version of that value, you probably wantDistribution.packages_dictorDistribution.source_mapping. (Note: 0.8.0 doesn't print source_mapping from the cli, but 0.9.0b2 or main does.)The "version mismatch" problem we've noted internally comes from something similar, being tracked in #4 -- depending on your application for the data, you might want to know that it's being read from a file, and if so which file, or you might just want the numeric result.
Related, dowsing currently doesn't emulate anything related to
package_data(because it's complex, easy to get wrong, and it's far safer to just include everything under a top-level dir). See comment at https://github.com/python-packaging/dowsing/blob/main/dowsing/types.py#L113 (and your py.wtf might be the "some people" it refers to).Future work:
See #70 for an overview of where I'd like to spend my time.
I'm mostly lacking test cases for the IDIC of setuptools-isms. If you have more, please send them my way! I've done a near-full analysis of pypi a couple of years ago focused on buildability from source, and may well do another on dowsing accuracy next chance I have good internet.
I also think it would be interesting to produce a package_dir and top-level mapping for all projects as a static json file you could just grab. I was able to fill in some gaps in static extraction by building in a well-stocked VM that has numpy, cffi, etc preinstalled in my last experiment. My various projects are increasinly interdependent (dowsing started out from a need in opine and checkdeps only knows about already-installed projects).