Add OMpy to pip - Githubissues

vetlewi commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

[ ] 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 commented 4 years ago

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

vetlewi commented 4 years ago

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

Version updating could be automatically done

fzeiser commented 4 years ago

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 commented 4 years ago

Or do you have any other/better suggestion?

fzeiser commented 4 years ago

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 commented 4 years ago

[ ] 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 commented 4 years ago

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

vetlewi commented 4 years ago

[ ] 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 commented 4 years ago

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 commented 4 years ago

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.

oslocyclotronlab / ompy

Add OMpy to pip #120