On Thu, Sep 27, 2018 at 5:38 PM Kaleb S. KEITHLEY <kkeithle@xxxxxxxxxx> wrote:
On 9/26/18 8:28 PM, Shyam Ranganathan wrote:
> Hi,
>
> With the introduction of default python 3 shebangs and the change in
> configure.ac to correct these to py2 if the build is being attempted on
> a machine that does not have py3, there are a couple of issues
> uncovered. Here is the plan to fix the same, suggestions welcome.
>
> Issues:
> - A configure job is run when creating the dist tarball, and this runs
> on non py3 platforms, hence changing the dist tarball to basically have
> py2 shebangs, as a result the release-new build job always outputs py
> files with the py2 shebang. See tarball in [1]
>
> - All regression hosts are currently py2 and so if we do not run the py
> shebang correction during configure (as we do not build and test from
> RPMS), we would be running with incorrect py3 shebangs (although this
> seems to work, see [2]. @kotresh can we understand why?)
Is it because we don't test any of the python in the regression tests?
Geo-replication do have regression tests but not sure about glusterfind, events.
Or because when we do, we invoke python scripts with `python foo.py` or
`$PYTHON foo.py` everywhere? The shebangs are ignored when scripts are
invoked this way.
The reason why geo-rep is passing is for the same reason mentioned. Geo-rep
python file is invoked from a c program always prefixing it with python as follows.
python = getenv("PYTHON");
if (!python)
python = PYTHON;
nargv[j++] = python;
nargv[j++] = GSYNCD_PREFIX "/python/syncdaemon/" GSYNCD_PY;
if (!python)
python = PYTHON;
nargv[j++] = python;
nargv[j++] = GSYNCD_PREFIX "/python/syncdaemon/" GSYNCD_PY;
>
> Plan to address the above is detailed in this bug [3].
>
> 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
>
> - All regression jobs will run with the above option, and hence this
> will correct the py shebangs in the regression machines. In the future
> as we run on both py2 and py3 machines, this will run with the right
> python shebangs on these machines.
>
> - The packaging jobs will now run the py version detection and shebang
> correction during actual build and packaging, Kaleb already has put up a
> patch for the same [2].
>
> Thoughts?
>
Also note that until --enable-whatever is added to configure(.ac), if
you're building and testing any of the python bits on RHEL or CentOS
you'll need to convert the shebangs. Perhaps the easiest way to do that
now (master branch and release-5 branch) is to build+install rpms.
If you're currently doing
`git clone; ./autogen.sh; ./configure; make; make install`
then change that to
`git clone; ./autogen.sh; ./configure; make -C extras/LinuxRPMS
glusterrpms`
and then yum install those rpms. The added advantage is that it's easier
to remove rpms than anything installed with `make install`.
If you're developing on Fedora (hopefully 27 or later) or Debian or
Ubuntu you don't need to do anything different as they all have python3.
--
Kaleb
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
--
Thanks and Regards,
Kotresh H R_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
