samba-tool ImportError: No module named param

Noel Power nopower at
Wed Dec 12 17:19:12 UTC 2018

On 12/12/2018 17:08, Alexander Bokovoy wrote:
> On ke, 12 joulu 2018, Noel Power via samba-technical wrote:
>> On 12/12/2018 16:08, Volker Lendecke wrote:
>>> On Wed, Dec 12, 2018 at 03:49:46PM +0000, Noel Power via 
>>> samba-technical wrote:
>>>> the default make builds and installs python3 products, the import 
>>>> statement
>>>> if failing because you are running ./bin/samba-tool (which by 
>>>> default on
>>>> your system is running with python2 because of the shebang)
>>>> if you run python3 ./bin/samba-tool  it will work
>>>> So, why haven't we changed the shebang to python3, there is 
>>>> currently some
>>>> discussion ongoing about that. It's not as clear cut as you think. In
>>>> general though scripts that are deliberately written to run with 
>>>> python2 &
>>>> python3 can have python in the shebang line. You need to be aware what
>>>> /usr/bin/python (or wherever it is located) is pointing at, in a 
>>>> system that
>>>> has python2 and python3 it might be /usr/bin/python could be a link to
>>>> either (and certainly in some newer enterprise focused distros I 
>>>> will bet
>>>> soon python -> python3), additionally you need to be aware of what your
>>>> build targets python2 or python3
>>> The python community really was smoking weird stuff when designing a
>>> completely new and incompatible language, naming it the same as the
>>> one before.
>> that's not quite true, the recommendation  is new code should use a 
>> shebang
>> appropriate to the version that is targetted python2 or python3 (or even
>> more finely grained python2.x or python3.x etc.) The exception is 
>> code that
>> is designed to work with both. /usr/bin/python in modern systems is a
>> placeholder (e.g. a link) the actual scripting interpreters are python2 &
>> python3 so it kindof makes sense to have the shebang names as it is to
>> reflect that.
> It is more complex than that. PEP-0394 
> (
> says, among other things:
> - If the python command is installed, it should invoke the same version
> of Python as the python2 command
didn't read that one :-)
> - One exception to this is scripts that are deliberately written to be
> source compatible with both Python 2.x and 3.x. Such scripts may
> continue to use python on their shebang line.
yep thats what I mentioned because at the moment (and for at least 4.10) 
we will afaics be in a compatible world, build deliverables though are a 
different matter because they really are targetted at a specific python 
version (there is also an ongoing discussion about whether there should 
be blanket changing of shebangs everywhere to python3)
> - When packaging software that is source compatible with both versions,
> distributions may change such python shebangs to python3. This ensures
> software is used with the latest version of Python available, and it
> can remove a dependency on Python 2.
and again that is something I think we probably should be doing
>>> We should make a blocker bug for 4.10. We can't ship with this mess.
>> it isn't as much of a mess as you think, the problem is that we probably
>> should be replacing the shebang on any python scripts (or tools) that are
>> delivered as part of the build (depending on which python version is
>> targetted). This is already something we are discussing but it is good to
>> get feedback. That's the purpose of getting in early into master so 
>> we can
>> iron these things out
> Yep. But having a bug serves several purposes here:
> - it ensures the work is completed before the release
> - it ensures the change or a choice of change is documentated in
> release notes
> - it ensures distributions are picking the change up
sure, I'm not objecting to the bug, just saying it isn't as bad a 
situation as it might appear


More information about the samba-technical mailing list