File collision advice

[Jerry James]

I would like some advice on this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=2036438

There are a number of packages with names of the form
python-sphinxcontrib-foo, which install their files into
%{python3_sitelib}/sphinxcontrib/foo/.  The issue is that at least two
of these, python-sphinxcontrib-asyncio and
python-sphinxcontrib-zopeext, install a file named
%{python3_sitelib}/sphinxcontrib/__init__.py, and the files are not
identical.

Any thoughts on how this should be dealt with are welcome.  I
suggested in the bug that we could introduce a package named simply
python-sphinxcontrib that owns both the sphinxcontrib directory and
the __init__.py file.  The other python-sphinxcontrib-* packages would
depend on it, and would not install any such __init__.py file.  There
is no such upstream package; this would be a Fedora construct simply
to deal with the file collision.  Perhaps we could even make that a
subpackage of python-sphinx.

Other ideas are welcome, especially if they mean less work for me. :-)
-- 
Jerry James
http://www.jamezone.org/

[Elliott Sales de Andrade]

On Tue, 4 Jan 2022 at 23:04, Jerry James <loganjerry(a)gmail.com&gt; wrote:
>  I would like some advice on this bug:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=2036438
>
>  There are a number of packages with names of the form
>  python-sphinxcontrib-foo, which install their files into
>  %{python3_sitelib}/sphinxcontrib/foo/.  The issue is that at least two
>  of these, python-sphinxcontrib-asyncio and
>  python-sphinxcontrib-zopeext, install a file named
>  %{python3_sitelib}/sphinxcontrib/__init__.py, and the files are not
>  identical.
>  
I think these packages are wrong upstream. The `sphinxcontrib`
directory is provided by python3-sphinx, and it specifically doesn't
have `__init__.py` there. Those extensions should not be adding one,
so as to keep the implicit namespace package nature of that directory:
https://packaging.python.org/en/latest/guides/packaging-namespace-package...

By the contents of the files, it appears they are trying to force it
to be a pkg_resources-style namespace package:
https://packaging.python.org/en/latest/guides/packaging-namespace-package...

But since Sphinx didn't do that in the first place, there's no
guarantee that other packages will contain `__init__.py` (and indeed
most do not).

>  Any thoughts on how this should be dealt with are welcome.  I
>  suggested in the bug that we could introduce a package named simply
>  python-sphinxcontrib that owns both the sphinxcontrib directory and
>  the __init__.py file.  The other python-sphinxcontrib-* packages would
>  depend on it, and would not install any such __init__.py file.  There
>  is no such upstream package; this would be a Fedora construct simply
>  to deal with the file collision.  Perhaps we could even make that a
>  subpackage of python-sphinx.
>
>  Other ideas are welcome, especially if they mean less work for me. :-)
>  --
>  Jerry James
>  http://www.jamezone.org/ 
-- 
Elliott

[Jerry James]

On Tue, Jan 4, 2022 at 11:59 PM Elliott Sales de Andrade
<quantum.analyst(a)gmail.com&gt; wrote:
>  I think these packages are wrong upstream. The `sphinxcontrib`
>  directory is provided by python3-sphinx, and it specifically doesn't
>  have `__init__.py` there. Those extensions should not be adding one,
>  so as to keep the implicit namespace package nature of that directory:
>
> https://packaging.python.org/en/latest/guides/packaging-namespace-package...
>
>  By the contents of the files, it appears they are trying to force it
>  to be a pkg_resources-style namespace package:
>
> https://packaging.python.org/en/latest/guides/packaging-namespace-package...
>
>  But since Sphinx didn't do that in the first place, there's no
>  guarantee that other packages will contain `__init__.py` (and indeed
>  most do not). 
Thank you, Elliott.  That's good information.  I will talk to the
respective upstreams about this.

Regards,
-- 
Jerry James
http://www.jamezone.org/

[Miro Hrončok]

On 05. 01. 22 17:38, Jerry James wrote:
>  On Tue, Jan 4, 2022 at 11:59 PM Elliott Sales de Andrade
>  <quantum.analyst(a)gmail.com&gt; wrote:
> > I think these packages are wrong upstream. The `sphinxcontrib`
> > directory is provided by python3-sphinx, and it specifically doesn't
> > have `__init__.py` there. Those extensions should not be adding one,
> > so as to keep the implicit namespace package nature of that directory:
> >
> https://packaging.python.org/en/latest/guides/packaging-namespace-package...
> >
> > By the contents of the files, it appears they are trying to force it
> > to be a pkg_resources-style namespace package:
> >
> https://packaging.python.org/en/latest/guides/packaging-namespace-package...
> >
> > But since Sphinx didn't do that in the first place, there's no
> > guarantee that other packages will contain `__init__.py` (and indeed
> > most do not).
>  
>  Thank you, Elliott.  That's good information.  I will talk to the
>  respective upstreams about this.
>   
For more context about Python namesapace packages, I recommend this thread 
(particularly Toshio's reply):

https://lists.fedoraproject.org/archives/list/[e-mail]...

As for the `sphinxcontrib` directory provided by python3-sphinx - note that 
this is done downstream.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok