-
Notifications
You must be signed in to change notification settings - Fork 184
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
Python3 shebang for 3.1.0 #2261
Comments
See MRtrix3/mrtrix3#2261 and MRtrix3/mrtrix3#2047. Am dropping python2 support for tractfinder because I like fstrings :)
Given the transition to CMake, I think providing a simple executable script in the installation directory that selects an appropriate shebang shouldn't be too much work. Previously, we had no delineation between build and install directories, so this might have been cumbersome, but that is no longer the case. Personally, however, I would prefer just to use |
Given that we merged #2958, can we close this? |
#2958 only deals with how a Python script already being executed will behave as it executes other Python scripts. It doesn't modify what will happen when an MRtrix3 Python script is first executed by the user from a shell. With the CMake-generated Python executables produced in #2920, there is technically the option of hard-coding the Python interpreter of choice into the shebang of those short files; this is how FSL gets their code to be interpreted by their custom Conda environment. However I don't think we want to be doing the same thing ourselves. For one, it wouldn't work for shipped compiled tarballs. Given your own prior comment, I had presumed that you would prefer those CMake-generated executables to change to |
Following #2958, I was under the (I guess wrong) impression that we wanted to hardcode the Python interpreter versions (including minor versions).
Yes, that still seems the most sensible option to me. |
I did invest a bit more effort in what you're talking about, but not for the reason you're subsequently inferring. The Python scripts (and the API more generally) can execute non-MRtrix3 commands, and those commands have shebangs outside of our control. Given we already had a mechanism for detecting when such a command is written for Python and utilising the same interpreter as that currently executing, I came to the realisation that if that command requests a specific minor version of Python3, and the currently executing interpreter does not match that, then the currently executing interpreter should not be used, as the specificity of that shebang may indicate a very specific dependency. So I'm trying to do something more clever in such circumstances, but only for speculative non-MRtrix3 shebangs, not reflecting an intent for MRtrix3 shebangs. Though thinking about it more now, I'm concerned the solution I have is no good. But I'll post that in #2958. |
Closed by #2966. |
Originally posted by @bjeurissen in #2047 (comment)
See #2047 and #2215.
D'Oh. Better to discover such while it's only on
dev
though.#!/usr/bin/env python3
, despite the recommendations against use ofenv
;configure
orbuild
. If however we had a script that set script shebangs, thenconfigure
could use logic of any arbitrary complexity to try to decide this, and those installing from pre-compiled packages could still use it if the default doesn't work on their system.The text was updated successfully, but these errors were encountered: