Open Alexander-Shukaev opened 5 years ago
When trying to reproduce this, I only get talib==0.1.1
in my generated requirements file. This should have a mapping in the pipreqs/mapping
file to make sure this import points to the desired library and prevent this incorrect one from being added.
To be honest, I don't understand why this mapping is needed at all. Why pipreqs
is not finding this out from setup.py
? This should be available at the installation site. In the worst case, this package meta information could be extracted from PyPI?
I'm not sure I follow. pipreqs
works by inspecting import statements and generating a requirements file. Which setup.py
file would it pull this information from? If you mean that we can extract the correct installable package name from the local environment, I think it's an interesting approach and would like to discuss how we'd go about doing so. One downside is that pipreqs
would output different results depending on the local environment, which isn't ideal, but controlling that feature with a CLI flag could be a reasonable approach.
If you mean that we can extract the correct installable package name from the local environment
That's exactly what I mean. E.g. in .venv/lib/python3.7/site-packages/TA_Lib-0.4.17.dist-info/METADATA
:
Metadata-Version: 2.1
Name: TA-Lib
Version: 0.4.17
Summary: Python wrapper for TA-Lib
Home-page: http://github.com/mrjbq7/ta-lib
Author: John Benediktsson
Author-email: mrjbq7@gmail.com
License: UNKNOWN
Download-URL: https://github.com/mrjbq7/ta-lib/releases
Platform: UNKNOWN
Classifier: License :: OSI Approved :: BSD License
Classifier: Development Status :: 4 - Beta
Classifier: Operating System :: Unix
Classifier: Operating System :: POSIX
Classifier: Operating System :: MacOS :: MacOS X
Classifier: Operating System :: Microsoft :: Windows
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3.3
Classifier: Programming Language :: Python :: 3.4
Classifier: Programming Language :: Python :: 3.5
Classifier: Programming Language :: Python :: 3.6
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: Cython
Classifier: Topic :: Office/Business :: Financial
Classifier: Topic :: Scientific/Engineering :: Mathematics
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Science/Research
Classifier: Intended Audience :: Financial and Insurance Industry
Requires-Dist: numpy
UNKNOWN
and in .venv/lib/python3.7/site-packages/TA_Lib-0.4.17.dist-info/top_level.txt
talib
I'm sure that it's possible to follow all these locations and extract all that metainfo just by the fact of being able to import
the package (e.g. talib
) via standard Python API.
I see #147 now, while I still believe that the whole challenge of mapping can be addressed by the approach proposed above. In case you feel like the above approach is too much to implement as a first step, I would say that apart from #147, you could consider providing users with configuration files, which would allow to alter the mapping (both adding and removing entries). I am certain that the right way to go about the implementation in this case would be to follow exactly what pip
does, i.e. Configuration, where you'd rename everything to be pipreqs
. Furthermore, I think it would be even more common for various projects to add/remove local project/repository mappings and also of course commit them. It means that both [pipreqs]
section in setup.py
and a standalone pipreqs.ini
in the root of project/repository (next to setup.py
) should also be supported (similar to how pytest
, tox
, and many others do it) and should obviously take precedence over previously-mentioned pip
-like configuration files.
P. S. I would still at least make a dirty sketch of the solution proposed above and test it in order to estimate the effort and impact.
Additionally, in either case, perhaps #134 needs to be taken up too.
Any plans to work on these ones? I personally think these are highly useful features. I'd welcome some additional opinions since maintainers have changed.
Somehow
import talib
(see TA-Lib) gives mewhere the first one is fine, while the second one seems to be nonsense as it results in error upon installation:
Shall this be blacklisted?