python: libsmb_samba_internal vs. libsmb

[Tim Beale]

OK, I agree it doesn't make sense to expose this API to external
consumers. I'll make a change to fix this up. Sorry for the
misunderstanding.

On 9/01/19 8:58 AM, Volker Lendecke wrote:
> On Tue, Jan 08, 2019 at 01:04:48PM +0100, Stefan Metzmacher wrote:
>> Hi Tim,
>>
>>> I wanted to rename the python module because the naming didn't seem
>>> consistent with any of the other python bindings Samba has. I think
>>> 'libsmb_samba_internal' made sense when it was unused by any of the
>>> samba python code (except some test code). But now (well, soon) these
>>> Python bindings will be used by the samba-tool code. It looks a bit
>>> strange in samba-tool to have:
>>>
>>> conn = libsmb_samba_internal.Conn(server)
>>>
>>> E.g. my latest patches start to use the new bindings in more places:
>>> https://gitlab.com/catalyst-samba/samba/commits/timb-pysmb-latest
>>>
>>> But maybe I've misunderstood something. Why do you want to keep the
>>> libsmb_samba_internal name?
>> The idea was that we make it clear that we don't expose a stable api
>> for external consumers. And we're free to change it without
>> consequences, as you did with the directory listing.
>>
>> samba-tool and other tools are not external consumers and would be
>> changed at the same time as we change the api.
>>
>> Volker, you invented the name, do you have any comments on this?
> I don't really remember that, but the argument that this is an
> internal API that has no stability guarantees is pretty convincing. We
> need a clear distinction between things we publish to our users and
> things that we can freely mess with. On the C side of things we have
> the (admittedly limited) libsmbclient and all the internal stuff that
> smbclient and winbind use. We can't restrict ourselves to an ABI/API
> for some things.
>
> Volker
>