Reasoning behind mapping requests to Requests (capitalization change)
I was wondering if there is any documentation anywhere that describes why some packages have their names remapped to something else. In particular I was curious about the requests package and the flask package. So if you have import requests in the code, pipreqs says "Found packages: {'requests'}", then "Found imports: Requests" but then "WARNING: Import named "Requests" not found locally. Trying to resolve it at the PyPI server." after which it ends up getting resolved to something like "requests:2.23.3", but then what gets written in the requirements file is "Requests==2.23.3"
I guess I don't really understand why this happens? I mean I understand how I guess, because its listed here in the mapping file https://github.com/bndr/pipreqs/blob/master/pipreqs/mapping#L994, but yeah not sure why.
Even in like a pip show requests, the name of the package is lowercase, so I'm not sure where this reference to a capitalized Requests package is coming from.
It's not a huge issue I suppose, it does warn you it didn't find it and is putting some other version into the requirements. Is this just something one should watch out for? For what its worth I've noticed it so far with requests and flask. And maybe flask is an even weirder example because on PyPI it says to install it with pip install Flask but the usage is from flask import Flask....
Sorry if this has been asked before and I just didn't find it, thanks for the work on this cool project
Some popular Python packages have different import names and package names (e.g., 'PIL' vs 'Pillow'). While pipreqs includes these mappings, it uses package names instead of import names when searching for installed versions, which can lead to version detection issues. The rationale behind mapping to capitalized package names also confuses me.
I've released a new library called ShowMeReqs, based on pipreqs' mapping data, that fixes this issue by using import names to find package versions. Feel free to give it a try if you're interested. https://github.com/SunandRiver/showmereqs
@SunandRiver that's a nice extension! What do you think of merging this logic into pipreqs itself?
@SunandRiver nice work, that looks great
@SunandRiver that's a nice extension! What do you think of merging this logic into pipreqs itself?
Thanks for the suggestion! That's a really good idea. I've been thinking about how we could merge some of ShowMeReqs' improvements into pipreqs. The main thing I changed was using import names directly to find package versions instead of relying on package name mappings - it seems to work better for cases like requests vs Requests. We could probably: Add this as an optional feature in pipreqs Keep the existing mapping files for backward compatibility Let users choose which method they prefer Sorry for the late reply by the way - I've been pretty busy lately and haven't been checking GitHub much. Thanks for being patient! If you're interested in this direction, I'd be happy to help prepare the code changes and documentation. We could start small and see how it goes. What do you think? Or has this already been implemented in pipreqs since it's been 4 months?