pip installation has errors when prerequisites are not installed

[gregoryng]

I am not sure if this is by design, but when you run pip to install subradar, but you don't have numpy installed, the install process fails. This might happen if you are setting up a fresh virtual environment.

(ve_sds1) freeze.ig.utexas.edu 135% pip3 install -r requirements.txt
Collecting bitstring>=3.1.5
  Using cached bitstring-4.1.4-py3-none-any.whl (60 kB)
Collecting pygdal>=3.2.1
  Using cached pygdal-3.7.2.12.tar.gz (5.4 kB)
Collecting h5py>=2.9.0
  Using cached h5py-3.10.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.8 MB)
Collecting matplotlib>=3.3.1
  Using cached matplotlib-3.8.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.6 MB)
Collecting scipy>=1.5.4
  Downloading scipy-1.12.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (38.5 MB)
     |████████████████████████████████| 38.5 MB 9.5 MB/s
Requirement already satisfied: numpy>=1.16.2 in ./ve_sds1/lib/python3.9/site-packages (from -r requirements.txt (line 6)) (1.26.4)
Collecting pandas>=0.24.2
  Using cached pandas-2.2.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (13.0 MB)
Collecting pvl>=0.3.0
  Using cached pvl-1.3.2-py2.py3-none-any.whl (66 kB)
Collecting spiceypy>=3.1.1
  Using cached spiceypy-6.0.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.7 MB)
Collecting geopandas>=0.8.1
  Using cached geopandas-0.14.3-py3-none-any.whl (1.1 MB)
Collecting pytest>=6.2.1
  Using cached pytest-8.0.0-py3-none-any.whl (334 kB)
Collecting rsr>=1.0.5
  Using cached rsr-1.0.7-py3-none-any.whl (17 kB)
Collecting subradar>=1.1.0
  Using cached subradar-1.1.2.tar.gz (15 kB)
    ERROR: Command errored out with exit status 1:
     command: /disk/kea/SDS/code/work/ngg/sds_tacc1/ve_sds1/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-dakzlyms/subradar/setup.py'"'"'; __file__='"'"'/tmp/pip-install-dakzlyms/subradar/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-rjbhi5nw
         cwd: /tmp/pip-install-dakzlyms/subradar/
    Complete output (9 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-install-dakzlyms/subradar/setup.py", line 6, in <module>
        import subradar
      File "/tmp/pip-install-dakzlyms/subradar/subradar/__init__.py", line 28, in <module>
        from . import iem, invert, roughness, surface, utils, filtering, simulation, fractal
      File "/tmp/pip-install-dakzlyms/subradar/subradar/iem.py", line 10, in <module>
        from scipy.special import factorial
    ModuleNotFoundError: No module named 'scipy'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
WARNING: You are using pip version 20.2.3; however, version 24.0 is available.
You should consider upgrading via the '/disk/kea/SDS/code/work/ngg/sds_tacc1/ve_sds1/bin/python3 -m pip install --upgrade pip' command.

A workaround is to manually install scipy and numpy first, but not sure if you should do that.

This is the contents of requirements.txt

bitstring>=3.1.5
pygdal>=3.2.1
h5py>=2.9.0
matplotlib>=3.3.1
scipy>=1.5.4
numpy>=1.16.2
pandas>=0.24.2
pvl>=0.3.0
spiceypy>=3.1.1
geopandas>=0.8.1
pytest>=6.2.1

rsr>=1.0.5
subradar>=1.1.0

[gregoryng]

subradar==1.1.2 may effectively have a circular dependency on rsr.

subradar 1.1.1 installs ok.

[cgrima]

The RSR circular dependency is fixed in v1.1.4.

That does not solve the dependency issue you are reporting , though. Oddly enough, I have a similar issue (ModuleNotFoundError: No module named 'numpy') when installing v1.1.4 on my laptop, but it does install smoothly on my Ubuntu server.

[gregoryng]

I started looking at how to make packages, and I see now that rather than the towardsdatascience article you had, there is now an official python tutorial:

https://packaging.python.org/en/latest/tutorials/packaging-projects/

I was looking at your code, and I see that one of the things you do is that you import a module in subradar in order to access the __version__ variable in the python code and use that in setup.

There is a bit of discussion about this maybe not being the best way to do versioning, and rather to place that metadata into the toml metadata file (in the comments under the original post):

https://stackoverflow.com/questions/458550/standard-way-to-embed-version-into-python-package

So removing the version variable and then not importing the code as part of the setup script seems like a better idea to me -- reduces risk of unwanted interactions. I guess the downside is that people can't query the version number within the code.

Edit: suggestions for version number https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#version