Second opinion needed on location of static arch independent data

[Jonathan Underwood]

Hi,

During the review of mkdocs[1], which is a python package for
generating static webpages, I (as reviewer) noticed that it installs a
lot of themes (javascript, fonts and the like) under
/usr/lib/python3/site-packages/mkdocs/themes.

My feeling is that this static architecture independent data should
really be installed under /usr/share/mkdocs to comply with the FHS[2].
But the packager (quite reasonably) points out that other packages
such as sphinx install templates and themes under
/usr/lib/python3/site-packages.

So, the question is: is it acceptable for this package to install arch
independent themes (i.e. non-python code) under
/usr/lib/python3/site-packages ?

TIA,
Jonathan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1230963
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE26

[Jonathan Underwood]

On 25 July 2015 at 01:37, Jonathan Underwood
<jonathan.underwood(a)gmail.com&gt; wrote:
>  Hi,
>
>  During the review of mkdocs[1], which is a python package for
>  generating static webpages, I (as reviewer) noticed that it installs a
>  lot of themes (javascript, fonts and the like) under
>  /usr/lib/python3/site-packages/mkdocs/themes.
>
>  My feeling is that this static architecture independent data should
>  really be installed under /usr/share/mkdocs to comply with the FHS[2].
>  But the packager (quite reasonably) points out that other packages
>  such as sphinx install templates and themes under
>  /usr/lib/python3/site-packages.
>
>  So, the question is: is it acceptable for this package to install arch
>  independent themes (i.e. non-python code) under
>  /usr/lib/python3/site-packages ?
>  
As an extra data point, it seems Debian places sphinx themes under /usr/share:

https://packages.debian.org/sid/all/sphinx-common/filelist

[Christopher Meng]

On Sat, Jul 25, 2015 at 10:59 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com&gt; wrote:
>  As an extra data point, it seems Debian places sphinx themes under /usr/share: 
You can't rely on Debian always in Fedora ;)

Will the new package with data moved to /usr/share work? Have you
tested? My opinion is to create a noarch for these static files and
let package depend on it. However you said there are also fonts so
it's tricky now.

[Jonathan Underwood]

On 25 July 2015 at 16:47, Christopher Meng <cickumqt(a)gmail.com&gt; wrote:
>  Will the new package with data moved to /usr/share work? Have you
>  tested? 
The package could be patched to work.

>  My opinion is to create a noarch for these static files and
>  let package depend on it. 
Splitting out the files into a sub-package is orthogonal to the
original question (and also not needed IMO).

>  However you said there are also fonts so
>  it's tricky now. 
The fonts have been unbundled and replaced with symlinks, as detailed
in the review ticket.

>  --
>  packaging mailing list
>  packaging(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/packaging

[William Moreno]

I am the packager of mkdocs.

During the review of mkdocs[1], which is a python package for
>  generating static webpages, I (as reviewer) noticed that it installs
> a
>  lot of themes (javascript, fonts and the like) under
>  /usr/lib/python3/site-packages/mkdocs/themes.
>
>  
python-sphinx Ipython python-werkzeug and python-django also put .js files
under %{python2_sitelib} or %{python3_sitelib} and this only a simple find
in my system, so it is safe to think than many python packages put arch
indepent data under %{python2_sitelib} and %{python3_sitelib} ,
removing  bundled
fonts and replaced with symlinks.

So all those packages must be fixed or mkdocs can put this data under
%{python3_sitelib}


>  My feeling is that this static architecture independent data should
>  really be installed under /usr/share/mkdocs to comply with the FHS[2].
>  But the packager (quite reasonably) points out that other packages
>  such as sphinx install templates and themes under
>  /usr/lib/python3/site-packages.
>
>  
For me the data under %{python3_sitelib} is arch indepent, Python code that
is not arch indepent is under %{python3_sitearch} so the arch independent
argument is not good enough to move these files.

See: https://en.opensuse.org/openSUSE:Packaging_Python#System_Architecture


So, the question is: is it acceptable for this package to install arch
>  independent themes (i.e. non-python code) under
>  /usr/lib/python3/site-packages ?
>
>  
For me put these files under  /usr/lib/python3/site-packages  is not a bad
packaging.

[Jonathan Underwood]

On 26 July 2015 at 00:13, William Moreno <williamjmorenor(a)gmail.com&gt; wrote:
[snip]
>  For me the data under %{python3_sitelib} is arch indepent, Python code that
>  is not arch indepent is under %{python3_sitearch} so the arch independent
>  argument is not good enough to move these files.
>  
You're misunderstanding my point. It's not the fact that it is arch
independent that is significant. This isn't about %{python3_sitelib}
vs. %{python3_sitearch} (both would be the wrong place for static
data). It's the fact that it is *static data* (and arch independent),
and not python library code. The FHS is very clear that static data
which is arch independent should go under /usr/share.

>  See:
> https://en.opensuse.org/openSUSE:Packaging_Python#System_Architecture
>  
There's nothing in that document germane to the issue as far as i can see.

As it goes, setuptools has ability to specify location of data files, see:

http://peak.telecommunity.com/DevCenter/setuptools#including-data-files


> > So, the question is: is it acceptable for this package to install arch
> > independent themes (i.e. non-python code) under
> > /usr/lib/python3/site-packages ?
> >
>
>  For me put these files under  /usr/lib/python3/site-packages  is not a bad
>  packaging. 

But your reasoning is simply "because other packages do it". I am
afraid I don't feel that is a valid argument.

Jonathan.

[Jonathan Underwood]

On 26 July 2015 at 01:07, Jonathan Underwood
<jonathan.underwood(a)gmail.com&gt; wrote:
[snip]
>  As it goes, setuptools has ability to specify location of data files,
> see:
>
>  http://peak.telecommunity.com/DevCenter/setuptools#including-data-files 
Discussing this with upstream here:

https://github.com/mkdocs/mkdocs/issues/697

it seems this whole issue is an unfortunate side-effect of mkdocs
reliance on entry points and that setuptools breaks the distutils
expectations of where data files are installed. The net result seems
to be that without re-engineering the whole python packaging stack
we're stuck with this situation. So, although it pains me greatly to
see such filesystem abuse, I think I am minded to say that this
shouldn't block mkdocs approval.

[Toshio Kuratomi]

On Jul 25, 2015 5:42 PM, "Jonathan Underwood"
<jonathan.underwood(a)gmail.com&gt;
wrote:
>  On 26 July 2015 at 01:07, Jonathan Underwood
>  <jonathan.underwood(a)gmail.com&gt; wrote:
>  [snip]
>  > As it goes, setuptools has ability to specify location of data files, 
see:
>  >
>  > http://peak.telecommunity.com/DevCenter/setuptools#including-data-files
>
>  Discussing this with upstream here:
>
>  https://github.com/mkdocs/mkdocs/issues/697
>
>  it seems this whole issue is an unfortunate side-effect of mkdocs
>  reliance on entry points and that setuptools breaks the distutils
>  expectations of where data files are installed. The net result seems
>  to be that without re-engineering the whole python packaging stack
>  we're stuck with this situation. So, although it pains me greatly to
>  see such filesystem abuse, I think I am minded to say that this
>  shouldn't block mkdocs approval. 
I don't believe I've blocked packages on this either, however it is
relatively simple to comply with the fhs and support the packages' notions
of file placement using symlinks.

There are some cases where I always moved the files and patched the code to
find it on the correct place: documentation, locales, man pages, fonts, and
such.  Those are things that have a specific type and specific place under
the fhs and fedora so it would be wrong to let those specific classes of
file go unmoved wherever upstream puts them.

-Toshio