[Gluster-devel] Python3 build process
srangana at redhat.com
Fri Sep 28 12:57:06 UTC 2018
On 09/28/2018 06:12 AM, Niels de Vos wrote:
> On Thu, Sep 27, 2018 at 08:40:54AM -0400, Shyam Ranganathan wrote:
>> On 09/27/2018 08:07 AM, Kaleb S. KEITHLEY wrote:
>>>> The thought is,
>>>> - Add a configure option "--enable-py-version-correction" to configure,
>>>> that is disabled by default
>>> "correction" implies there's something that's incorrect. How about
>>> "conversion" or perhaps just --enable-python2
>> I would not like to go with --enable-python2 as that implies it is an
>> conscious choice with the understanding that py2 is on the box. Given
>> the current ability to detect and hence correct the python shebangs, I
>> would think we should retain it as a more detect and modify the shebangs
>> option name. (I am looking at this more as an option that does the right
>> thing implicitly than someone/tool using this checking explicitly, which
>> can mean different things to different people, if that makes sense)
>> Now "correction" seems like an overkill, maybe "conversion"?
> Is it really needed to have this as an option? Instead of an option in
> configure.ac, can it not be a post-install task in a Makefile.am? The
> number of executable python scripts that get installed are minimal, so I
> do not expect that a lot of changes are needed for this.
Here is how I summarize this proposal,
- Perform the shebang "correction" for py2 in the post install
- Keeps the git clone clean
- shebang correction occurs based on a configure time option
- It is not implicit but an explicit choice to correct the shebangs to
py2, hence we need an option either way
- The configure option would be "--enable-python2"
- Developers that need py2, can configure it as such
- Regression jobs that need py2, either because of the platform they
test against, or for py2 compliance in the future, use the said option
- Package builds are agnostic to these changes (currently) as they
decide at build time based on the platform what needs to be done.
> There do seem quite some Python files that have a shebang, but do not
> need it (__init__.py, not executable, no __main__-like functions). This
> should probably get reviewed as well. When those scripts get their
> shebang removed, even fewer files need to be 'fixed-up'.
I propose maintainers/component-owner take this cleanup.
> Is there a BZ or GitHub Issue that I can use to send some fixes?
More information about the Gluster-devel