bndr / pipreqs

pipreqs - Generate pip requirements.txt file based on imports of any project. Looking for maintainers to move this project forward.
Apache License 2.0
6.09k stars 380 forks source link

TA-Lib #142

Open Alexander-Shukaev opened 5 years ago

Alexander-Shukaev commented 5 years ago

Somehow import talib (see TA-Lib) gives me

TA_Lib==0.4.17
talib==0.1.1

where the first one is fine, while the second one seems to be nonsense as it results in error upon installation:

Building wheels for collected packages: talib
  Running setup.py bdist_wheel for talib ... error
  Complete output from command /home/user/<project>/.venv/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-qlpggc_h/talib/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/pip-wheel-bgpomtii --python-tag cp37:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib
  creating build/lib/talib
  copying talib/cli.py -> build/lib/talib
  copying talib/__init__.py -> build/lib/talib
  installing to build/bdist.linux-x86_64/wheel
  running install
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/tmp/pip-install-qlpggc_h/talib/setup.py", line 47, in <module>
      'talib = talib.cli:cli',
    File "/usr/lib/python3.7/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/usr/lib/python3.7/distutils/dist.py", line 966, in run_commands
      self.run_command(cmd)
    File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
      cmd_obj.run()
    File "/home/user/<project>/.venv/lib/python3.7/site-packages/wheel/bdist_wheel.py", line 224, in run
      self.run_command('install')
    File "/usr/lib/python3.7/distutils/cmd.py", line 313, in run_command
      self.distribution.run_command(command)
    File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
      cmd_obj.run()
    File "/tmp/pip-install-qlpggc_h/talib/setup.py", line 20, in run
      raise Exception("You probably meant to install and run ta-lib")
  Exception: You probably meant to install and run ta-lib

Shall this be blacklisted?

jonafato commented 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.

Alexander-Shukaev commented 5 years ago

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?

jonafato commented 5 years ago

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.

Alexander-Shukaev commented 5 years ago

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.

Alexander-Shukaev commented 5 years ago

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.

Alexander-Shukaev commented 5 years ago

Additionally, in either case, perhaps #134 needs to be taken up too.

Alexander-Shukaev commented 3 years ago

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.