Re: [PATCH RFC] scripts/sphinx-pre-install: add a script to check Sphinx install

[Mauro Carvalho Chehab]

Em Sun, 16 Jul 2017 09:29:35 +0200
Markus Heiser <markus.heiser@xxxxxxxxxxx> escreveu:

> Hy Mauro,
> 
> thanks a lot for your RFC, your patch consolidate a lot of
> knowledge around Sphinx build requirements and brings a huge
> value I will no longer miss.
> 
> I tested v6 of this patch on ubuntu and there is only some
> conceptual bikeshedding I can do. 
> 
> 
> > Am 15.07.2017 um 14:49 schrieb Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx>:
> > 
> > As I said, the idea is to let the user to decide what it wants.
> > 
> > I focused on the packaging approach first because such logic
> > is required for other packages. Now that it is working, just
> > sent a version 5 that will use virtualenv for Sphinx by default.  
> 
> Thanks! .. I don't know how I can make it better (I'am not a perl
> programmer) but it seems, that global
> 
> my @missing;
> my @opt_missing;

We could use a hash here, instead, placing the "optional" as
an attribute.

> and the "sub add_package" is dominant, while the 'virtaulenv'
> is glued in .. may we can find a better structure (later).

Yeah, for sure some things there could be simplified.

> > Yet, before spending more time on such script, I'd like to have
> > more feedback if:
> > 
> > 	- is this approach acceptable?  
> 
> Truly Yes!

Good! I'll try to add support today for Gentoo. I suspect that
this is the last major distribution that people use.

> I see, there is a value in the the "OS-packaging approach" even
> if I prefer the  "native-packaging approach". Last means I like
> to use the native packaging tools from python and LiveTeX.

I know some Kernel devs that even package the Kernel they
built for their own consumption with rpm or dpkg - even taking a 
lot more time to do that ;)

The thing if using the OS-packaging is that the packaging tool
can be used to check everything installed at the system, with
makes a lot easier when installing a package or upgrading.

For example, when I upgraded my system to Fedora 26, as python
changed from version 3.5 to version 3.6, I had to destroy the
virtual envs and re-create them again. If I had used, instead,
the OS-packaging, that would be transparent. The same happens if
I wanted to upgrade Sphinx packages to a newer version.

> For python, instead of :
> 
> 		printf "\t$virtualenv sphinx_1.4\n";
> 		printf "\tpip install 'docutils==0.12'\n";
> 		printf "\tpip install 'Sphinx==1.4.9'\n";
> 		printf "\tpip install sphinx_rtd_theme\n";
> 
> add Documentation/sphinx/requirements.txt:
> 
> <snip: requirements.txt> ---
> docutils==0.12
> Sphinx==1.4.9
> sphinx_rtd_theme
> <snap> ---------------------
> 
> And the print ...
> 
> 		printf "\t$virtualenv sphinx_1.4\n";
> 		printf "\tpip install -r Documentation/sphinx/requirements.txt\n";

Yeah, I can do that.

> 
> For TexLive:
> 
> ATM I have no idea how to set up a *requierements* file and
> install everything without sudo. But I have seen your 'kpsewhich'
> approach  which is very interesting for me. I suppose a solution
> for this will end in a combination of 'kpsewhich' and  'tlmgr'.

I see two problems with tlmgr:

- tlmgr is not installed by default (at least on Fedora);
- adding packages with other package managers makes admin
  process a way more complex for upgrades and security fixes.

That's why I opted to use only kpsewhich.

> But for this I have to do more investigations / sorry that
> I can't spend more time on this task right now.
> 
> > 	- should it have an optional argument that will make the
> > 	  script to run the needed commands;  
> 
> No. We can do this later upstream.
> 
> > 	- should it be integrated at the Documentation/Makefile?  
> 
> No.
> 
> > 	- what's the best name/location for such script?  
> 
> I like to see the script under Documentation/sphinx

If the idea is to run the scripts standalone, scripts/ is a better
place.

> 
> > I guess it could also use kpsewhich to check if the needed
> > texlive packages are installed. However, the problem with such
> > approach is that texlive-kpathsea-bin package should be installed
> > first, in order to provide such command.  
> 
> I see you have solved it in v6 .. Thanks!

Yes. It works fine for Fedora and OpenSuse. No need for Debian or
Arch Linux, as texlive is lot less granular there.

Didn't check yet how Gentoo packages it.

> > So, installing PDF and math dependencies would require two steps.
> >   
> >> I tested sphinx-pre-install and it works fine for me, thats not the
> >> point. The point is: what do we recommend? E.g. for me it advices me
> >> to run:
> >> 
> >> 	sudo apt-get install python3-sphinx python3-sphinx-rtd-theme
> >> 
> >> We should not assume that the developer (better: the build-user) owns the
> >> privilege to install fine grained OS packages. There is a admin-part and
> >> a user-part:  
> > 
> > That's not relevant. Typically, anyone that is building a Kernel has
> > admin privileges, otherwise it can't actually test the Kernel that was
> > built.  
> 
> Hmm .. buildbots and Continuous Integration (CI)?

I'm pretty sure that buildbots will use OS-packaging: a build bot farm
could easily become an admin nightmare if the packages are not managed
by a single package management system.

Thanks,
Mauro