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

Update README re: Python 3 #22

Closed
wants to merge 1 commit into from
Closed

Update README re: Python 3 #22

wants to merge 1 commit into from

Conversation

molpopgen
Copy link

The fence for executable code doesn't work on systems where python is not an alias for python3. This change suggests how to fix.

The fence for executable code doesn't work on systems where python is not an alias for python3.  This change suggests how to fix.
@gpoore
Copy link
Owner

gpoore commented Aug 19, 2020

Thanks for the suggestion! I'll make sure that is clarified in the README for the next release.

I've actually thought about using shutil.which() to automatically swap the executable from python to python3 when python3 exists...there must be a version of Python 3 installed if text2qti is running. Do you have any thoughts about that?

@molpopgen
Copy link
Author

It may be a bit more straightforward to internally check which Python interpreter is being run via sys:

In [7]: sys.version_info                                                                     
Out[7]: sys.version_info(major=3, minor=8, micro=2, releaselevel='final', serial=0)
In [8]: sys.version_info.major                                                               
Out[8]: 3

You can use the major version to decide to call python3.

@molpopgen
Copy link
Author

there must be a version of Python 3 installed if text2qti is running. Do you have any thoughts about that

I just noticed that your README does say that 3.6 or later is required. In that case, I think it is harmless to simply say that the code fence should say {.python3 .run}. In a conda environment with Python 3, python is just a symlink/alias to python3. I imagine that python3 has to exist as an executable because 2/3 co-installations are going to exist for some time.

gpoore added a commit that referenced this pull request Sep 12, 2020
…te; README now suggests using .python3 in executable code blocks to be more explicit (#22); added executable keyword argument for executable code blocks; added support for periods in executable code block language attributes
@gpoore
Copy link
Owner

gpoore commented Sep 12, 2020

I've added a note about using .python3 in the README. I've also modified the handling of .python, so that it uses python3 on systems where python is equivalent to python2 (those systems now require an explicit .python2 to use python2). And I've added the option of specifying an executable path for code blocks via executable=<executable> to provide even more customization.

@gpoore gpoore closed this Sep 12, 2020
@gpoore gpoore added documentation Improvements or additions to documentation enhancement New feature or request labels Sep 12, 2020
@molpopgen molpopgen deleted the patch-1 branch September 13, 2020 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants