Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python: provide post-install instructions #2205

Closed
dbrnz opened this issue Oct 31, 2019 · 7 comments
Closed

Python: provide post-install instructions #2205

dbrnz opened this issue Oct 31, 2019 · 7 comments
Assignees
Labels
Milestone

Comments

@dbrnz
Copy link
Contributor

dbrnz commented Oct 31, 2019

It is essential that the setpythonpath script is run after unarchiving an OpenCOR+Python release, as otherwise the scripts in Python's ./bin directory (./Scripts under Windows) don't contain the correct path to OpenCOR's Python. One symptom of things being wrong is !pip list failing when run in the GUI Python console.

A note to this effect should be attached to releases on Github.

Note: the Windows' installer does the right thing.

@agarny agarny self-assigned this Oct 31, 2019
@agarny agarny added the Task label Oct 31, 2019
@agarny agarny added this to the 0.7 milestone Oct 31, 2019
@agarny
Copy link
Contributor

agarny commented Oct 31, 2019

Good point. However, I am not sure we want to rely on the end user running that script upon unzipping or installing OpenCOR. People are bound to forget about it (especially when upgrading from one version/snapshot to another). So, couldn't we have that script run automatically when starting OpenCOR. Surely, it ought to be possible, somehow? (In the same way that we register the OpenCOR URI when starting OpenCOR.) This would also allow for people to move/rename the OpenCOR directory, if they need/want, without having to worry about anything. (And this means that we wouldn't need to run that script as part of the Windows installer.)

I will look into it when I have a minute.

@dbrnz
Copy link
Contributor Author

dbrnz commented Oct 31, 2019

Yes, good point to automatically run the script, and we have discussed doing so before now...

One way to do this would be to call PythonQtSupport::evalFile() (or evalScript()) at the end of PythonQtSupportPlugin::initializePlugin() -- we just need to work out how best to pass the relevant parameters. In fact, modifying set_python_path.py to determine appropriate default parameters (and using evalFile()) would be the simplest.

Shall I do so and generate a pull request??

@agarny
Copy link
Contributor

agarny commented Oct 31, 2019

Shall I do so and generate a pull request??

Yes, that would be great. Thanks!

dbrnz added a commit to dbrnz/opencor that referenced this issue Nov 1, 2019
dbrnz added a commit to dbrnz/opencor that referenced this issue Nov 1, 2019
…o longer during installation or when running Jupyter or Python (opencor#2205).
dbrnz added a commit to dbrnz/opencor that referenced this issue Nov 1, 2019
…o longer during installation or when running the Python shell (opencor#2205).
@agarny
Copy link
Contributor

agarny commented Nov 1, 2019

Closing as per PR agarny#10.

@agarny agarny closed this as completed Nov 1, 2019
@agarny
Copy link
Contributor

agarny commented Nov 1, 2019

Having merged in PR agarny#10 and rebuilt our Python package, I can confirm that it's all working fine (i.e. our Python scripts' shebang gets properly updated).

I will just do a couple of things:

  1. Merge setpythonpath into runjupyter since it's only used there.
  2. Move runjupyter and runpython out of the OpenCOR home directory since a user should never have to run those scripts directly.

@dbrnz
Copy link
Contributor Author

dbrnz commented Nov 1, 2019

Isn't runpython something a user would run? Say renamed as pythonshell??

Or since it's just a convenience wrapper for OpenCOR -c PythonShell, do we simply remove it and document (for power users) how to run the CLI plugin? And users can alias python="/path/to/OpenCOR -c PythonShell" if they want to.

@agarny
Copy link
Contributor

agarny commented Nov 1, 2019

Hmm, I guess we might keep it, but rename it to pythonshell indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants