expose python strategy

[casperdcl]

most of this (see original description below) is migrated to SyneRBI/SIRF#163

new description

• depends on sirf python packaging SIRF#163
  • use PYTHON_STRATEGY (CONDA|SETUP_PY|PYTHONPATH)
  • example: cmake -DSIRF_TAG=setup_py -DPYTHON_STRATEGY=SETUP_PY

original description

• provides setup.py
  • provides sirf
  • alias p(Gadgetron|STIR|Utilities) to sirf.p(Gadgetron|STIR|Utilities) for backward-compatibility
• cmake -> pip install -> setup.py
• depends on Fix python dest SIRF#160 (or don't override external PYTHON_DEST SIRF#161)
• register sirf on PyPI before anyone else does (https://pypi.org/project/sirf/)

old

• INSTALL/
  • python/
    • *.(py|so)

new

• INSTALL/
  • python/
    • setup.py
    • sirf/
      • __init__.py
      • *.(py|so)
    • p*/__init__.py

future

• (ana)conda @paskino
• register sirf on conda-forge
• setup.py:build_ext to call cmake @casperdcl
  • https://stackoverflow.com/a/48015772/3896283
  • won't need to re-implement cmake call in conda
  • will need to pass cmake build args to setup.py (pretty easy)

[KrisThielemans]

hi. I didn't check this yet, but quite a few extra changes here related to Docker etc. intentional?

[casperdcl]

yes, it's some fairly no-brainer docker tidy up, would probably merge that in separately first (#110 )

[casperdcl]

@paskino please note my comment in the description about using setup.py to call cmake - in which case we might be able to get away with

1. install miniconda
2. install requirements using apt-get (possibly almost nothing since most things might be on conda?)
3. conda install -c conda-forge sirf (will auto-install dependencies, then run setup.py on sirf-superbuild which will run cmake and make)

[paskino]

Casper is setup.py already calling cmake to build sirf?

[casperdcl]

No, but I could make it that way. Right now the procedure is:

1. apt-get requirements (cmake, boost, etc)
2. create python virtualenv and install python requirements
3. cmake && make (will build everything as before, except for the following changes:)
   • PYTHONPATH is no longer altered anywhere
   • setup.py is generated and used in a pip install command to automatically pick up built python modules

[paskino]

Maybe that's not necessary then. conda recipe currently covers 1 and 2. If we split 3 in:

3.a cmake && make
3.b python setup.py install

I guess I could just merge this branch in the conda branch adding 3.b

[KrisThielemans]

I don't see the benefit of splitting into 3a and 3b. "make" already calls setup.py. why split it?

I also don't think letting setup.py do cmake&&make is a good idea. It means you cannot build MATLAB and Python in one go.

(obviously, in the conda script you wouldn't want to call make but cmake --build -C Release or whatever the syntax is).

[paskino]

The conda built SIRF works, except #111

[casperdcl]

btw, docker image sizes for different python sources:

• virtualenv: 2.84GB
• miniconda: 2.98GB
• miniconda (update --all): 3GB

[KrisThielemans]

I feel that the SIRF specific stuff (i.e. 90%) should be in the SIRF repo itself, but not sure if that'd lead to a ton of duplication.
If we need to keep it here, it definitely needs to be in a separate file, presumably called from External_SIRF.cmake

[KrisThielemans]

is this ok? shouldn't it use PYTHONINTERP?

[casperdcl]

should be fine, mainly just for correct syntax highlighting despite the .in extension - it's never executed directly (always ${PYTHON_EXECUTABLE} setup.py, not ./setup.py) so is ignored anyway