Suggestions for rlm_python

Geaaru geaaru at gmail.com
Sun Nov 3 17:10:06 CET 2019


Cool. Perfect. I will test it and I will integrate py3 support to
Gentoo ebuild.
Just a note. Why doesn't use pkgs-config in configure.ac?
This seems broken in Gentoo/Sabayon with python-3.6.9:
$# python3 -c 'import sys ; print(sys.version[[0:3]])'  File
"<string>", line 1    import sys ;
print(sys.version[[0:3]])                                     ^SyntaxEr
ror: invalid syntax
The output is this:
$ python3 -c 'import sys ; print(sys.version)'3.6.9 (default, Aug  8
2019, 20:57:56) [GCC 8.2.0]
I think that the correct way could be:
$# python3 -c 'import sys ; print(sys.version[0:3])'3.6
With pkg-config it's pretty easy set vars indeed:
PY_BASE_MOD_LIBS=`pkg-config --libs python-${PY_SYS_VERSION}`
and it isn't needed add manually -lm.
Yeah, i know, pkg-config is not always available but if it's present
why doesn't use it.
My cent.
On Sun, 2019-11-03 at 10:12 -0500, Alan DeKok wrote:
> On Nov 3, 2019, at 5:04 AM, Geaaru <geaaru at gmail.com> wrote:
> > I began to work on rlm_python3 support. Unlucky, there are a lot
> > ofthings to change because a lot of used methods must be changed,
> > forexample:
> > PyString_FromString -> PyUnicode_FromString
> > I think that also initialization of the module has also big
> > changes.
> > So, how could be the right way to handle this module?
> 
>   We've already merged a rlm_python3 into the v3 branch.  We've had a
> few reports from people that it works.
>   Can you double-check it?  We'd like to do 3.0.20 soon.
> > Probably, for a period it's better to have two modules rlm_python
> > (for2.7) and rlm_python3 (for 3.x) but from another site, it's
> > wrong toleave to the user the possibility of loading both modules.
> > I dunno whathappens with GIL, etc. with both modules loaded and
> > probably it'sbetter to avoid this.
> 
>   They're independent libraries, so it shouldn't be a problem.  If it
> is, well, don't use both modules.
> > In addition, py 2.7 is EOL so probably it's better to avoid
> > splitting.
> > It is not an easy choice.
> 
>   It's not an option to change the behaviour of the existing
> rlm_python.  So we've opted to go with a new module.
>   Alan DeKok.


More information about the Freeradius-Devel mailing list