All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Heiser <markus.heiser@darmarit.de>
To: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH RFC] scripts/sphinx-pre-install: add a script to check Sphinx install
Date: Sat, 15 Jul 2017 11:51:45 +0200	[thread overview]
Message-ID: <1719549A-CDF5-4448-8CD6-28B52802E00A@darmarit.de> (raw)
In-Reply-To: <20170714232140.0608da3c@vento.lan>


> Am 15.07.2017 um 04:21 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> 
> Em Fri, 14 Jul 2017 19:35:59 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> 
>>> Am 14.07.2017 um 18:49 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>>> 
>>> Solving Sphinx dependencies can be painful. Add a script to
>>> check if everything is ok.  
>> 
>> just my 5cent:
>> 
>> What we need is a "requirements.txt" file to define a
>> **reference environment**. E.g. to stick Sphinx 1.4.9 in
>> such a reference environment::
>> 
>> <snip: requirements.txt> ---
>> Sphinx==1.4.9
>> sphinx_rtd_theme
>> <snap> ---------------------
>> 
>> The rest is similarly to what you wrote in doc-guide/sphinx.rst ...
>> 
>> The ref-environment can be build with virtualenv & pip::
>> 
>> $ virtualenv --python=python3 docenv
>> (doc-env) $ source ./docenv/bin/activate
>> (doc-env) $ pip install -r requirements.txt
>> 
>> From now we can start our build as usual. If not already done,
>> first activate the environment::
>> 
>> $ . ./docenv/bin/activate
>> (doc-env) $ make htmldocs
>> 
>> This (requirements.txt) is the way python packaging goes.
> 
> 
> The above assumes that the user wants to use virtenv and
> have python3, virtualenv3 and pip3 already installed.
> 
> I agree that a virtual environment works better than using
> distro-specific packaging, as Sphinx toolchain is really
> fragile. But we should give an option for the developer to
> use whatever he wants.

The developer is free to choose the way he like. But we are talking
about what is "best practice".

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:

The admin (sudoer) installs binaries into the OS:

* gcc
* make
* python3, virtualenv
* LiveTex
* ImageMagick
* perl
* graphviz

The user (developer) installs additional requirements anywhere
under $HOME:

* Python 

  best practice here is virtualenv and pip .. and the *recipe*
  to get a *reference environment* is the requirements.txt
 
* LaTeX

  what is best practice here? .. I know there is some package
  managing with "TeX Live Manager" (tlmgr) but I have no experience
  with. Is there a way to define a *requirements* file and
  to install such requirements anywhere under $HOME?

My english is less eloquent, but I hope its clear what I mean.

To have a script is nice, but first lets explore what best practice
is.


-- Markus --

  reply	other threads:[~2017-07-15  9:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14 16:49 [PATCH RFC] scripts/sphinx-pre-install: add a script to check Sphinx install Mauro Carvalho Chehab
2017-07-14 17:35 ` Markus Heiser
2017-07-14 22:51   ` Jim Davis
2017-07-15  1:27     ` Mauro Carvalho Chehab
2017-07-15  2:21   ` Mauro Carvalho Chehab
2017-07-15  9:51     ` Markus Heiser [this message]
2017-07-15 12:49       ` Mauro Carvalho Chehab
2017-07-15 12:55         ` Mauro Carvalho Chehab
2017-07-15 19:27           ` Mauro Carvalho Chehab
2017-07-16  7:29         ` Markus Heiser
2017-07-16  9:57           ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1719549A-CDF5-4448-8CD6-28B52802E00A@darmarit.de \
    --to=markus.heiser@darmarit.de \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=mchehab@s-opensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.