Closed rhfogh closed 1 year ago
Looks good to me in general, thanks !
For the dockerfile
I cant see from where you are getting mxcubecore ?
"For the dockerfile I cant see from where you are getting mxcubecore ?" Actually I am not. in start_mxcube the pythonpath is set to $MXCUBE_BASE/mxcubeqt:$MXCUBE_BASE/mxcubecore and MXCUBE_BASE is set also in start_mxcube and mounted on the docker. The effect is that mxcubeqt and mxcubecore are assumed to eb in parallel directories, and the directory containing them is passed in and mounted. The point is that I do not want to have mxcubecore as a subdirectory of mxcubeqt, since they are separate repositories adn in development and it all gets messy. This was the way I found to get it working without that.
Ok, simply running poetry install
in the mxcubecore
directory should work then I think. Otherwise those dependencies should come with the installation of mxcubecore
in requirements_python3.txt
right ?
"_I miss the bit where you "install" the mxcubeqt module i.e use requirementspython3.txt"
Again, I actually do not. requirements_python2.txt and requirements_python2.txt are not used at all, currently - I just did not want to delete them before it was clear what we wanted to do. But then they are not needed, currently. pyqtgraph is installed in the Dockerfile, and mxcubecore is handled as a separate repository and not installed via pip, so I know exactly what I am getting and do not need to go via an install step. And apart from pyqtgraph and mxcubecore there is nothing in those requirement files. setup.py and requirements_mxcubecore.txt I added myself, and the latter contains all the requirements that are otherwise in teh mxcubecore pyproject.toml, since the latter is not used..
I guess you see why I wanted to discuss how this can be improved or reconciled with the normal way of installation?
"Ok, simply running poetry install in the mxcubecore directory should work then I think"
It did not work for me. I got either error message about modules not being defined, or I got problems with the fact that you can only access subdirectories of the directory containing the docker code. Anyway I could not find a way to do it. And I would really prefer not to have mxcubecore as a subdirectory of mxcubeqt while doing development work.
Maybe I should explain what I am trying to do here - in part because maybe someone can tell me I ought to be doing something else ;-)
This docker is intended for development, not distribution. I want to be able to keep editing the MXCUBE code without having to reinstall or remake the docker. For that reason, mxcubeqt, mxcubecore and the GPhL code are kept outside the docker, in separate repositories, and only the code dependencies are installed in the docker. As a separate point I wanted to avoid having mxcubecore as a subdirectory under mxcubeqt, since it can get quite messy with git repositories inside other git repositories.
But I was worried that this would not fit in the normal approach particularly well.
So Ill merge this as it is in the mean time as we agreed on the meeting we had.
Added docker with installation mechanisms using commercial PyQt version, and tests for using licensed versions only.
NB the install machinery is a hack - the mxcubecore requirements are in requirements_mxcubecore.txt instead of using the mxcubecore pyproject.toml. This is undesirable, but I could not get the docker installation to work in any other way. Also, there might be a better location of these files than the top level of mxcubeqt
I would very much welcome if someone could check that the docker making works and ideally tell me of a better way to make the docker and handle the installation
The way to run the docker is to make it using the dockerfile, and then run start_mxcube, after editing to adapt to local directlry structure.