JuPedSim / jpsreport

Analysis tool
https://www.jupedsim.org/jpsreport_introduction.html
Other
3 stars 9 forks source link

Calling python instead of python3 leads to problems when importing modules #55

Closed chraibi closed 5 years ago

chraibi commented 5 years ago

In Gitlab by @JuleAdrian on Aug 6, 2018, 13:45 [origin]

In the commit 8f2f3ebe the python call within MethodD was changed from python3 to python. 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?

chraibi commented 5 years ago

In Gitlab by @JuleAdrian on Aug 6, 2018, 13:46

changed the description

chraibi commented 5 years ago

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?

chraibi commented 5 years ago

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.

chraibi commented 5 years ago

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 ...

chraibi commented 5 years ago

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.

Screen_Shot_2018-08-07_at_17.19.40

Screen_Shot_2018-08-07_at_17.22.57

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 with jpsreport? The python call from jpsreport is very slow ...

Agree. Any suggestions?

chraibi commented 5 years ago

In Gitlab by @gjaeger on Aug 7, 2018, 11:39

@chraibi

Yes, is there a way to solve this in the cmake-file?

chraibi commented 5 years ago

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! =)

chraibi commented 5 years ago

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.

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 12, 2018, 13:14

In the commit 8f2f3ebe the python call within MethodD was changed from python3 to python.

@PaulGeoerg could you please check if python3 works for you? I prefer to revert to commit 8f2f3ebe.

chraibi commented 5 years ago

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!

chraibi commented 5 years ago

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 by jpsreport.

A good suggestion!

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 15, 2018, 12:34

closed via commit 2dfb2f3279afb23570516bb715d555f24f4a525b

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 15, 2018, 12:34

closed via commit 641c1bd84bdafd7329e74f803e4ba8f124a41eed

chraibi commented 5 years ago

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?

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 15, 2018, 15:11

reopened

chraibi commented 5 years ago

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:

chraibi commented 5 years ago

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?

chraibi commented 5 years ago

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.

chraibi commented 5 years ago

In Gitlab by @gjaeger on Sep 15, 2018, 16:13

commit 5fb97f3244f488e1ef30cd79ac33785492c74751: Can I help you?

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 15, 2018, 18:26

Sure :+1:

chraibi commented 5 years ago

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)?

chraibi commented 5 years ago

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.

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 18, 2018, 08:52

Is this issue solved? Close?

chraibi commented 5 years ago

In Gitlab by @gjaeger on Sep 18, 2018, 09:03

Does it work for all operating systems? Did you test it?

chraibi commented 5 years ago

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.

windows7

Screen_Shot_2018-09-18_at_10.16.05

chraibi commented 5 years ago

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?

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 18, 2018, 11:33

Because of boost, since python check issues a warning only.

chraibi commented 5 years ago

In Gitlab by @gjaeger on Sep 18, 2018, 11:33

If not, let's close this issue.

@JuleAdrian : Is your issue answered?

chraibi commented 5 years ago

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!

chraibi commented 5 years ago

In Gitlab by @chraibi on Sep 18, 2018, 15:00

@JuleAdrian can you do that?

chraibi commented 5 years ago

In Gitlab by @chraibi on Oct 4, 2018, 18:29

closed

chraibi commented 5 years ago

In Gitlab by @chraibi on Nov 5, 2018, 11:46

mentioned in commit 641c1bd84bdafd7329e74f803e4ba8f124a41eed

chraibi commented 5 years ago

In Gitlab by @chraibi on Nov 5, 2018, 11:46

mentioned in commit 2dfb2f3279afb23570516bb715d555f24f4a525b