Add OMpy to pip

[vetlewi]

It might be about time to consider uploading OMpy as a package on the pypi repository, simplifying the installation considerable.

The packaging and uploading of the package should probably be done automatically through travis-ci or similar tools.

[fzeiser]

In principle possible; there is some questions we should think of.
[ ] Check or make sure people have installed MultiNest (not only PyMultiNest)
[ ] Advise on how to download submodules (response)
[ ] Versioning -- when to release new versions, how to call them (...)

What would you suggest doing about this?

[vetlewi]

[ ] Check or make sure people have installed MultiNest (not only PyMultiNest)

The install script should fail if MultiNest is not found. The built-in ctypes library has the function ctypes.util.find_library() that can be used to check for MultiNest. This is the same function that PyMultiNest uses to find the library.

[ ] Advise on how to download submodules (response)

Either one could ship the most used response functions or set up functionality that fetches the response functions from the repository from GitHub.

[ ] Versioning -- when to release new versions, how to call them (...)

I suggest following this schema.

[fzeiser]

Do you think that people (after us?) will remember to update the version when they make changes?

[vetlewi]

Do you think that people (after us?) will remember to update the version when they make changes?

Version updating could be automatically done

[fzeiser]

I guess my concern was (mostly towards) what is solved in here: https://stackoverflow.com/questions/42718373/increase-version-number-if-travis-at-github-was-successful

Do you want to set it up? If I should do it it, it might have to wait some time.

[fzeiser]

Or do you have any other/better suggestion?

[fzeiser]

The install script should fail if MultiNest is not found. The built-in ctypes library has the function ctypes.util.find_library() that can be used to check for MultiNest. This is the same function that PyMultiNest uses to find the library.

The install of PyMultiNest via pip does not fail if Multinest is not found. It will complain once you try to import it

[fzeiser]

[ ] Advise on how to download submodules (response)

Either one could ship the most used response functions or set up functionality that fetches the response functions from the repository from GitHub.

Hm, that's interesting. I don't think it's good to ship hem with the code via pip. That will just make things very large. But we could of course have

• an install script:
  • pip install ompy
  • if not found, download ond compile multinest
  • download response functions
• alternative: get_response method in the response class
  • if one provides OSCAR or Cactus, it looks on the disk. If it doesn't find it, it can download the data o a default folder.

[fzeiser]

The latter alternative does not help on the MultiNest issue, of course.

[vetlewi]

[ ] Advise on how to download submodules (response)

Either one could ship the most used response functions or set up functionality that fetches the response functions from the repository from GitHub.

Hm, that's interesting. I don't think it's good to ship hem with the code via pip. That will just make things very large. But we could of course have

• an install script:

  • pip install ompy
  • if not found, download ond compile multinest

Alternatively one could fork pymultinest and use scikit-build.readthedocs.io to build the multinest package?

• download response functions

• alternative: get_response method in the response class

  • if one provides OSCAR or Cactus, it looks on the disk. If it doesn't find it, it can download the data o a default folder.

I think a static get_response method is a good choice!

[fzeiser]

• I think I step back from automatically pushing to pypi. I think we would get lot's of lot's of new versions. Maybe not each small fix in a docstring that one pushed needs to go to pypi? Any opinions on this @vetlewi @ErlendLima ?
• response function: static get_response method
• Multinest: Yep, it seems somewhat easier/saver to complain when installing ompy, then installing it and complaining when we start to import it

[fzeiser]

Got an error when trying to upload the package to pypi.

❯ python3 -m twine upload --repository testpypi dist/*
Uploading distributions to https://test.pypi.org/legacy/
Uploading OMpy-1.0.1-cp37-cp37m-linux_x86_64.whl
100%|█████████████████████████████████████████| 464k/464k [00:02<00:00, 221kB/s]
NOTE: Try --verbose to see response content.
HTTPError: 400 Client Error: Binary wheel 'OMpy-1.0.1-cp37-cp37m-linux_x86_64.whl' has an unsupported platform tag 'linux_x86_64'. for url: https://test.pypi.org/legacy/

The problem is, I think, the cython modules that are complies for my system. Seems like I need to upload them with manylinux, see
https://github.com/pypa/manylinux and a demo on how to do it with travis: https://github.com/pypa/python-manylinux-demo.

Will have a look at it later.
Resolution on automatic pushing: whenever there is a new tag (release), test and push to pypi.