Can you please make the new parskip "opt-in" and not "opt-out" ?

[jfbu]

We got a report at Sphinx (Python documentation tool) about diverging builds on Windows and Linux. This is caused by parskip having been extended recently. Now for legacy reasons Sphinx LaTeX used parskip per default. The change means all documents produces via Sphinx now are unstable because when people update locally their TeX installations, they don't get the same page numbering etc.., whereas at sites like RTD the online docs of (zillions of) Python (mainly) projects will keep the old layout.

We can not use option [=v1] as this will not be recognized by old installations.

A separate issue is that by default the new parskip loads etoolbox which is a big dependency. This would have caused problems formerly as we needed to support very old TeX installations, but we are now requiring TL2013 and soon 2015. But if "opt-in" behaviour is to be added, it would be nice to make the loading of etoolbox also conditional on this.

The following document

\documentclass{article}
\usepackage{parskip}
\usepackage{titlesec}
\usepackage{blindtext}
\begin{document}
\section{Overview}
\blindtext
\end{document}

changes from TL2017 to my updated TL2018. This is really a problem!

[davidcarlisle]

actually `\usepackage{parskip}[=v1]` works on older installations. in tl2018 it uses the rollback version to load parskip-2001-04-09. but on older installations (I just tried tl2017 and tl2016) the option is silently ignored and the the (old) parskip.sty is loaded, David

…

On Wed, 16 Jan 2019 at 23:34, Jean-François B. ***@***.***> wrote: We got a report <sphinx-doc/sphinx#5960> at Sphinx (Python documentation tool) about diverging builds on Windows and Linux. This is caused by parskip having been extended recently. Now for legacy reasons Sphinx LaTeX used parskip per default. The change means all documents produces via Sphinx now are unstable because when people update locally their TeX installations, they don't get the same page numbering etc.., whereas at sites like RTD <https://readthedocs.org/> the online docs of (zillions of) Python (mainly) projects will keep the old layout. We can not use option [=v1] as this will not be recognized by old installations. A separate issue is that by default the new parskip loads etoolbox which is a big dependency. This would have caused problems formerly as we needed to support very old TeX installations, but we are now requiring TL2013 and soon 2015. But if "opt-in" behaviour is to be added, it would be nice to make the loading of etoolbox also conditional on this. The following document \documentclass{article}\usepackage{parskip}\usepackage{titlesec}\usepackage{blindtext}\begin{document}\section{Overview}\blindtext\end{document} changes from TL2017 to my updated TL2018. This is really a problem! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNcAm9ULysmxmCPulVCfjRpjjNUMremks5vD7bygaJpZM4aEKmU> .

[jfbu]

This is good to know but does not apply to TL2012

! Missing number, treated as zero.
<to be read again> 
                   =
l.2 \usepackage{parskip}[=v1]
                             
?

[jfbu]

Does not work on TL2013, 2014, 2015 either.

[jfbu]

Does not work on TL2016:

$ pdflatex bugparskip
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./bugparskip.tex
LaTeX2e <2017/01/01> patch level 3
Babel <3.9r> and hyphenation patterns for 52 language(s) loaded.
(/usr/local/texlive/2016/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2016/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2016/texmf-dist/tex/latex/parskip/parskip.sty)
! Missing number, treated as zero.
<to be read again> 
                   =
l.2 \usepackage{parskip}[=v1]
                             
? 

Only works with TL2017 at my locale.

$ pdflatex bugparskip
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/MacPorts 2017_2) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./bugparskip.tex
LaTeX2e <2017-04-15>
Babel <3.18> and hyphenation patterns for 52 language(s) loaded.
(/usr/local/texlive/2017/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2017/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2017/texmf-dist/tex/latex/parskip/parskip.sty)
(/usr/local/texlive/2017/texmf-dist/tex/latex/titlesec/titlesec.sty)
(/usr/local/texlive/2017/texmf-dist/tex/latex/blindtext/blindtext.sty
(/usr/local/texlive/2017/texmf-dist/tex/latex/tools/xspace.sty))
(./bugparskip.aux) [1{/usr/local/texlive/2017/texmf-var/fonts/map/pdftex/updmap
/pdftex.map}] (./bugparskip.aux) )</usr/local/texlive/2017/texmf-dist/fonts/typ
e1/public/amsfonts/cm/cmbx12.pfb></usr/local/texlive/2017/texmf-dist/fonts/type
1/public/amsfonts/cm/cmr10.pfb>
Output written on bugparskip.pdf (1 page, 25497 bytes).
Transcript written on bugparskip.log.

[jfbu]

Alternative would be to release the new version under a new name parskip2 etc...

[davidcarlisle]

sorry it's late and my message was nonsense. It does work in _my_ texlive 2016 but that has the 2017-04-01 format with the rolback code, it wpn't work in older versions.

…

On Thu, 17 Jan 2019 at 00:15, Jean-François B. ***@***.***> wrote: Alternative would be to release the new version under a new name parskip2 etc... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[FrankMittelbach]

I think essentially what you are saying is that it is a problem for Sphinx if anywhere in LaTeX bugs are corrected that lead to layout changes. parskip is an example as it was not producing in places what it was set out to do. But it is by no means that only one.

However, I don't really think that this is a practical approach accross multiple releases of LaTeX to assume that a single cross-ref into multiple locally produced docs using different software is actually guaranteed to be stable. We do try very hard to not alter document layouts but sometimes that can't be helpd and not to correct bugs because that isn't really a good solution in my eyes either.

The suggestion of option-in is something I don't favor because the past has shown that this isn't working well, ie people don't use it most of the time, and it is also questionable that the default should be the buggy version. Same goes for providing new names and packages side by side ---- we have already many too many packages that a are broken, do not worth well with each other etc to add to that pool.

The rollback approaches are precisely there for getting rid of this issue and the fact that you are hit by being in the timeframe where both with and without releases exist is understandably a problem, but doesn't really convince me to comeup with parskip2.

My proposal therefore is that you use this

\IfFileExists{parskip-2001-04-09.sty}
   {\usepackage{parskip}[=v1]}
   {\usepackage{parskip}}

to always load the legacy version of parskip in the Sphinx documentation class

[jfbu]

Thanks for

\IfFileExists{parskip-2001-04-09.sty}
   {\usepackage{parskip}[=v1]}
   {\usepackage{parskip}}

having not examined the file structure of the new package, I did not think about this. This clearly solves it.

It is a fact of life that I have to support people with old TeX installs. At my home workplace until 4 years ago, it was TeXLive 2004 and impossible to modify that, and impossible to install own TeXLive due to space quotas. Well I am lying a bit, it was possible to install it on an /import volume not cared about by sysadmins.

Anyway, don't say "I think essentially what you are saying is that ..." and then add words which I did not say.

I do not argue that perhaps indeed parskip influenced layout was buggy, have you taken into account that perhaps we or other people added some vspace in their layouts decided on basis of what was the output with a parskip having not changed in 17 years ?

I am ready at next major release to announce that PDF layout changed (I have not examined the situation, perhaps the new layout is better, I don't know), but for this Sphinx will have to ship new parskip and let its LaTeX writer add it to all build repertories.

Am I guaranteed then that future titlesec which Sphinx uses too will not break current patches done by parskip ? No I am not, and clearly this is additional maintenance burdain.

What is the problem in saying that parskip is deprecated and parskip2.0 the recommended one? At Sphinx, we are all for the best and brightest and would in due time (4 or 5 years from now when we lift our requirements to TeXLive 2019) make the shift to the new one.

Anyway, the fix you propose can indeed serve as temporary solution during the next few years. Thanks.

[FrankMittelbach]

Jean-François

Anyway, don't say "I think essentially what you are saying is that ..." and then add words which I did not say.

sorry I had no intention of putting words in your mouth that you didn't say. All I was trying was to summarize how I understood the situation of what you said (or implied). And seriously, is my summary incorrect, as far is what the underlying issue for Sphinx is --- with any change in any LaTeX packages or the kernel?

I do not argue that perhaps indeed |parskip| influenced layout was buggy, have you taken into account that perhaps we or other people added some vspace in their layouts decided on basis of what was the output with a parskip having not changed in 17 years ?

I think so. I agree it is an difficult question of what is best, and it is also a philosophical one I guess and and maybe I'm wrong. But fact is, that to process old documents you have =v1 if you indeed have fixed the layout bugs manually or if you want to ensure to get the old buggy behavior. The Sphinx situation is a bit out of the norm here I would say with the dependencies on multiple versions while trying to have 100% compatibility. But honestly, if 100% compatibility is assumed why should there be any different versions or bug fixes? each fix will end up making a change otherwise it isn't a fix and each such change will affect at least theoretically some documents. so if that is the goal you can only add in new releases and even that can break documents

Am I guaranteed then that future |titlesec| which Sphinx uses too will not break current patches done by parskip ? No I am not, and clearly this is additional maintenance burdain.

first of all that would be a burden on parskip maintenance I would say, because it would be my task to follow changes in titlesec if they happen, but yes any change is a burden to maintainers and dependencies don't really help I grant you that. On the other hand, the heading macros of LaTeX (and titlesec) have a serious bug which reveals itself if you use a positive parskip in that they add that more than once so two speak.

What is the problem in saying that |parskip| is deprecated and |parskip2.0| the recommended one? At Sphinx, we are all for the best and brightest and would in due time (4 or 5 years from now when we lift our requirements to TeXLive 2019) make the shift to the new one.

The problem is that it doesn't work on several accounts. Most LaTeX users tend to copy one preamble from one document to the next and inherit it from friends that teach them LaTeX. Just look at the fact that you still see epsfig.sty in bug reports that got deprecated in 1994! So unless you change the main package you will not gain traction and even if you do you will at best end up with a divided community of which a certain fraction uses one and the other a different version. Also you end up with dependencies to several different versions, eg some other code then doesn't only has to know if package X got loaded or not but also if it was X or Xb or Xc. We had this kind of problem very badly with the fixltx2e approach. Also, I just went over 5000+ CTAN packages recently, half of them are broken, not maintained, slight variants of others etc (ok, perhaps not half) but if you talk about maintenance nightmare I see that on the LaTeX front too and by adding packages over packages rather than consolidating the situation is not help in my opinion. In my opinion an overhaul and cleanup is overdue, because otherwise we will end up with a really unmaintainable situation. And yes there is some fallout along the way. Maybe, my take on the parskip situation was wrong and does need to be revised but for now I would like to stay on this path by consolidating + fixing (with rollback)

[nioncode]

Upfront: I don't have any clue about update cycles of packages or distributions like TeX Live.
However, as a user, I thought building a PDF with a TeX Live distribution of a given version (2018) would give the same results, no matter if I install it on the day it was first released or one day before the new version (2019) gets released.

When upgrading to a different TeX Live version, then I'd understand that there are updated packages integrated that might have breaking changes, but for me this was totally unexpected when having the same major revision. Do distributions not give any compatibility guarantee during a major version?

[FrankMittelbach]

@nioncode if you build with a given version of TL then you should get the same result. But the question is what is "the version of TL"

there is a yearly DVD cut version but between those date you can enable updates (or you can refrain from) and you can make this auto-update or manual ... which is all very convenient depending on your scenario as a single user, but it means that different intstallations may have different levels of the software. And MikTeX is even more agressive in that it basically changes even the binaries the moment they hit the central archive.

So in that sense there is not a "major version". From a maintainer perspective (say, the LaTeX3 team for the kernel software) this is a problem but it is like that for ages, it is just the way these distributions are being made.

[nioncode]

Ok, then this was just a misunderstanding of mine regarding how TL handles its releases. Basically, when you install TL 2018 at date x and at date y you will likely get different package versions that might contain breaking changes.

So someone wanting to have identical output from different machines must make sure to have the exact same version of TL and its packages installed.

[jfbu]

@nioncode Linux distros such as Ubuntu uses a Debian based packaging of LaTeX which builds up on TeXLive but at some specific instant of time. This is why at Sphinx we have to say things

like this

The testing of Sphinx LaTeX is done on Ubuntu trusty with the above mentioned packages, which are from a TeXLive 2013 snapshot dated February 2014.

or that

The testing of Sphinx LaTeX is done on Ubuntu xenial whose TeX distribution is based on a TeXLive 2015 snapshot dated March 2016.

which are not precise enough but give some indication.

@FrankMittelbach Thanks for the explanations.

[FrankMittelbach]

I'll close this given that there is a workaround, please ping me here if the issue resurfaces in a different way.