Hello Thomas, On Mon, 10 Jun 2024 at 12:03, Thomas Goirand <z...@debian.org> wrote: > > On 6/9/24 18:47, Samuel Henrique wrote: > > Zigo, > >> I just saw that sherlock (the social networks package) moved its python > >> files to /usr/share, instead of /usr/lib/python3/dist-packages > >> . This was > >> the sensible thing to do, as it doesn't really need to expose itself as > >> Python module. > > > > Not really, that was done by accident when Nilson was trying to remove the > > system-wide init file (#1071007) and was reverted already. > > > > Upstream has mentioned (to me) that their intention is to provide a library > > for > > sherlock, as we've had since the package was introduced. > > Well, sherlock is an app, and therefore, it's the sensible thing to do > to push it's Python code in /usr/share. IMO, it shouldn't have been > reverted.
The move was done as a workaround for another issue (the global __init__ file), and upstream mentioned they would like to have the module available, so at the time the revert was the right choice. Now that we know there's also a clash with the sherlock package, the situation is different. > Normally, the one that owns the PyPi name such as: > https://pypi.org/project/sherlock/ > > also get to have the python module name. Clearly, sherlock (the social > media package) didn't do that. I agree with this. > Now, if you know upstream, then probably you can convince them to rename > their lib to something that doesn't clash? And also, maybe, add its > software on PyPi? Sherlock is there, but under https://pypi.org/project/sherlock-project. So it does look like the right thing to do on Debian's side is to either not let the module be importable or rename it (ideally done by upstream first). Paul (as upstream), the sherlock module clashes with https://pypi.org/project/sherlock/, which was published first and ships a "sherlock" library. Do you think it would make sense to change the name of the module provided by your sherlock (just the module, not the executable), or alternatively for us to not ship an importable library at all? This is an issue that's going to happen on other distros as well, as far as I know. > >> Therefore, this bug can be closed, and there's IMO nothing more to do in > >> the python-sherlock (the cluster lock package), as the conflict is now > >> solved. > > > > I'll reopen 1072733 since the clash still exists. > > :( We have a path forward now, at least after Paul replies, so it should be all good (although the bug stays open until solved, right?!). Cheers, -- Samuel Henrique <samueloph>
