Closed chraibi closed 5 years ago
In Gitlab by @JuleAdrian on Aug 6, 2018, 13:46
changed the description
In Gitlab by @PaulGeoerg on Aug 6, 2018, 14:01
I am not sure if I have understood you properly: I could work around by setting a system variable to the correct python path. But that is not the question, right?
In Gitlab by @JuleAdrian on Aug 6, 2018, 14:09
The question is: Why don't we just call python3
if we want to use python3
and if the scripts only work with python3?
For me, the workaround with an alias doesn't work. Maybe I can find another workaround.
But anyway, it is preferable, if the user does not need to create a workaround.
In Gitlab by @gjaeger on Aug 6, 2018, 14:17
How about if the python query is done in the compilation process? (e.g. cmake)?
Why do we associate python
with jpsreport
? The python
call from jpsreport
is very slow ...
In Gitlab by @chraibi on Aug 7, 2018, 11:28
@JuleAdrian your default python is 2.7 and not 3 then?
In my case, this leads to a call of python2.7 instead of python3.6 although I have set an alias
python=python3
.
actually should work. Maybe source your config file.
Is there any reason why not to change all calls to python3? Or any other suggestion on how to deal with this problem?
If I remember correctly, I made this change, because I had problems running jpsreport on some Windows machine.
@gjaeger
Why do we associate
python
withjpsreport
? Thepython
call fromjpsreport
is very slow ...
Agree. Any suggestions?
In Gitlab by @gjaeger on Aug 7, 2018, 11:39
@chraibi
Yes, is there a way to solve this in the cmake-file?
In Gitlab by @PaulGeoerg on Aug 7, 2018, 11:40
If I remember correctly, I made this change, because I had problems running jpsreport on some Windows machine.
You're right, mate. I am probably the only one who works with jpsreport on a win-machine, right? So I take a look on my 'workaround-notes' and found this! =)
In Gitlab by @JuleAdrian on Aug 7, 2018, 13:39
@chraibi : Yes, python2.7
is installed by default... Sourcing the config file didn't work either. The alias is working, when I call python
in the terminal. It just doesn't work when python
is being called by jpsreport
.
The real question is: Isn't e.g. Python Version 3.6 always callable by python3
or python3.6
? Do we really need to force the user to make this version callable by python
?
@chraibi @gjaeger: If we really need a python (Version 3.*) call from jpsreport
, I agree that cmake should search for the corresponding interpreter. Then this interpreter should be called by jpsreport
.
In Gitlab by @chraibi on Sep 12, 2018, 13:14
In the commit 8f2f3ebe the python call within MethodD was changed from
python3
topython
.
@PaulGeoerg could you please check if python3
works for you?
I prefer to revert to commit 8f2f3ebe.
In Gitlab by @PaulGeoerg on Sep 12, 2018, 21:03
@chraibi : Absolutly - it doesn't work. Don't know why. But to be honest to you and as mentioned before, it makes sense to call for python3
. I will not update jpsreport any more until finish my project and plot all my stuff by own scripts. Do the reversion, mate!
In Gitlab by @gjaeger on Sep 15, 2018, 11:22
@chraibi @gjaeger: If we really need a python (Version 3.*) call from
jpsreport
, I agree that cmake should search for the corresponding interpreter. Then this interpreter should be called byjpsreport
.
A good suggestion!
In Gitlab by @chraibi on Sep 15, 2018, 12:34
closed via commit 2dfb2f3279afb23570516bb715d555f24f4a525b
In Gitlab by @chraibi on Sep 15, 2018, 12:34
closed via commit 641c1bd84bdafd7329e74f803e4ba8f124a41eed
In Gitlab by @gjaeger on Sep 15, 2018, 12:37
@chraibi Why do you close the issue if there is no solution yet? Or what is the solution?
In Gitlab by @chraibi on Sep 15, 2018, 15:11
reopened
In Gitlab by @chraibi on Sep 15, 2018, 15:11
The issue was automatically closed with my commit, that calls python3
instead of python
.
I reopen it because I'm working on another idea... :sunglasses:
In Gitlab by @gjaeger on Sep 15, 2018, 15:22
What are you doing? commit 641c1bd8 calls python3
instead of python
. commit 2dfb2f32 calls python
instead of python3
.
Do you want to describe your idea?
In Gitlab by @chraibi on Sep 15, 2018, 15:36
Via cmake
python interpreter is detected.
This line gives a warning in case python3 is not installed. (did not check this else yet, since it's hard to find a system without python3)
This solution should work in linux and MacOS. Windows needs to be tested yet.
In Gitlab by @gjaeger on Sep 15, 2018, 16:13
commit 5fb97f3244f488e1ef30cd79ac33785492c74751: Can I help you?
In Gitlab by @chraibi on Sep 15, 2018, 18:26
Sure :+1:
In Gitlab by @gjaeger on Sep 16, 2018, 12:11
It's a serious question.
You write:
did not check this else yet, since it's hard to find a system without python3
This solution should work in linux and MacOS. Windows needs to be tested yet.
Can we use the gitlab CI/CD process for this? Does it make sense to use test environments (for Linux, MacOS, Windows)?
In Gitlab by @chraibi on Sep 16, 2018, 22:04
Can we use the gitlab CI/CD process for this?
We already use Gitlab CI/CD. Right now jpsreport
does not compile, because the Gitlab runner runs on an image with an old version of g++.
(not our problem, but going to be solved by the admins, hopefully)
Does it make sense to use test environments (for Linux, MacOS, Windows)?
Yes, but probably not in Gitlab. I know some online solutions, like TraVis. It's not better than GitLab CI, since does not support Windows and it triggers tests only when we push to GitHub.
Other solutions that support windows, e.g. appveyor are not free.
I hope, GitLab CI offers one-day solutions for Windows and OSX, although, for license reasons, it might be difficult.
For the time being, I already tested the "else"-branch on a Debian image with Python2 installed.
In Gitlab by @chraibi on Sep 18, 2018, 08:52
Is this issue solved? Close?
In Gitlab by @gjaeger on Sep 18, 2018, 09:03
Does it work for all operating systems? Did you test it?
In Gitlab by @chraibi on Sep 18, 2018, 11:25
Yes, see screenshots for Windows 7, OSX and Linux (Debian).
You guys, please check if you have any problems after this commit.
If not, let's close this issue.
In Gitlab by @gjaeger on Sep 18, 2018, 11:31
to Linux (Debian): Is cmake aborted because python could not find or boost could not find?
In Gitlab by @chraibi on Sep 18, 2018, 11:33
Because of boost, since python check issues a warning only.
In Gitlab by @gjaeger on Sep 18, 2018, 11:33
If not, let's close this issue.
@JuleAdrian : Is your issue answered?
In Gitlab by @JuleAdrian on Sep 18, 2018, 14:39
Mostly! For method D, it works fine!
But, there are still hard-coded python
calls in Method_A.cpp and Method_B.cpp.
When this is changed as well, the issue can be closed!
In Gitlab by @chraibi on Sep 18, 2018, 15:00
@JuleAdrian can you do that?
In Gitlab by @chraibi on Oct 4, 2018, 18:29
closed
In Gitlab by @chraibi on Nov 5, 2018, 11:46
mentioned in commit 641c1bd84bdafd7329e74f803e4ba8f124a41eed
In Gitlab by @chraibi on Nov 5, 2018, 11:46
mentioned in commit 2dfb2f3279afb23570516bb715d555f24f4a525b
In Gitlab by @JuleAdrian on Aug 6, 2018, 13:45 [origin]
In the commit 8f2f3ebe the python call within MethodD was changed from
python3
topython
. Why is that?In my case, this leads to a call of python2.7 instead of python3.6 although I have set an alias
python=python3
. And this leads to problems when importing certain modules that are bound to python3 such as Polygon.When I change all Python calls to
python3
, everything works fine. The calls appear in Analysis.cpp, Method_A.cpp and Method_D.cpp.Is there any reason why not to change all calls to python3? Or any other suggestion on how to deal with this problem?