#29 simplify the setup.py

[Frédéric PICCA]

Hello armando

here a patch that use numpy distutils part.
this way the build of numpy Extensions is tomy opinion more robust.
Non need to deal with numpy specific part.

It also reduce the number of lines in the setup.py. :)

cheers

Fred

[V. Armando Sole]

Hi Fred,

I really do not see any major advantage than to remove the numpy.get_include() ... Personally I prefer to have it explicit.

Please beware I was changing the directory layout while you were working at your side.

I think what we should find out is a way to deal with the data files during the build phase. My tests check if everything goes well after installation, but debian and sphinx test during build...

Armando

[Frédéric PICCA]

Hello Armando,

this is just that building a numpy extension is more than just adding the include files. In understand the explicit part but importing numpy.distutils is also explicit.

I agree with you that this data files need some love. I find this PyMcaData things too tricky and error prone. We should get rid about it and follow the guidata way, use a dedicated function to access the data pf pymca.
So we should have to deal with the data path only in this place.
no file generation (embeded in the setup.py) during the build process would be nice.

I was looking at your refactoring.

don't you think that it is a good time for pymca to follow the pep8 and to not use capital in the Module names.

also you are putting (tomy opinion) too much PyMca everywhere :)

PyMca.PyMcaIO -> PyMca.io (no ?) it is easyer to remember and to type.

even better

pymca.io (no more upper case, quicker to type)

I think that PyMca should be rename pymca (this non upper case is due to some file system which are not case sensitiv).

my two cents.

Cheers

Fred

[V. Armando Sole]

I think what is important is to be consistent.

I use lowercase for the scripts.

For the rest, I try to follow the CamelCase style of Qt.

Concerning pep8, the underscore is a nightmare whenever one changes keyboard and having so many Qt widgets around, I think CamelCase is not so bad. There are just some old modules that are not consistent with any convention.

I was hesitating between PyMca.PyMcaIO or PyMca.IO
I had chosen the former for analogy to FabIO and to avoid something as generic as IO

For instance, your suggestion to follow pep8 and io (PyMca.io) would run into problems with the python io module: http://docs.python.org/2/library/io.html

Conerning too much PyMca around, it has to do with the need to supply ready-to-use frozen binaries. I would prefer to use "from . import" or "from .. import" and so on, but then the frozen versions would not work.

The non-frozen version was happy just moving all the files to the PyMcaIO directory and the from PyMcaIO import * in the init.py, but then cx_freezer was not able to build the frozen binary and I had to modify a lot of files.

Armando