New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test more packages before publishing a new release #1530
Comments
That's not an issue: we build a minimal TeX Live for our tests anyway - it's just a question of what to include. (This means the install is updated every day from CTAN.)
The problems here are
Now, one might decide this is a reasonable balance, but at least when we looked before it felt fragile. |
It is faster to install a Docker image than manually install TeX Live and lots of packages. And the docker image contains all files needed. Also these tests could be run at the same time when
It is still useful even if package loading is tested only.
Step 1 and Step 2 together mainly catch latex bugs. And the team could still decide not to consider these tests as release blockers and upload new releases to CTAN as before. |
Rather, it contains too many: you need to be selective :)
I forgot to add (3): one has to decide for every package involved if the issue is a LaTeX or a package bug.
Nope: releases can only go if the test suite passes. |
I.e. the current cache size is only ~240 Mb. |
Previous discussion was in In a more general aspect, people want an as smooth as possible experience in updating (La)TeX packages because the package managers of TeX Live and MiKTeX both don't support per-project package and package version locking. Maybe latex3 packages could have a set of |
The team have been discussing this: there are some downsides but obviously potential upsides too. We are likely to talk 'in person' about it next week before reaching a conclusion. |
Another idea: technically it's possible to write an action which fetches the latest files in Just technically. |
Sure, but that most likely helps devs who are already relatively 'involved' - ones with for example an existing testing setup. My take on the original question is it's more aimed at people who are not in that position. (And yes, it's unfortunate that |
I created a new repository https://github.com/lvjr/pkgstatus and write some code for experiments. First I removed
Then I renamed
|
Well your own ignorelist shows the problem with this approach: It contains for example Naturally nothing prevents you (or someone else) to setup such a testsuite. You can pull in the newest latex sources, run the tests and notify us if you think that there is a problem with the format. |
Could you please read the title of this issue again? I am not talking about testing ALL packages but MORE packages. Even tesing 3953 packages is a large improvement and the team could decide which packages must be included or excluded.
I have heard this kind of sentences several times. |
The issue comes in that if there's a breakage, one has to decide what to do. Much of the time, issues arise which are. highlighted by a LaTeX change, but are not (formally) 'caused' by a LaTeX change, i.e. something was already broken compared to the formal API, etc. One then has to decide how to handle things. Excluding a 'broken' package is easiest but doesn't help (other than as a record), asking a dev to fix may or may not be successful, fixing via some firstaid approach is sometime necessary but isn't something that scales well, etc. |
I am not meant to require responsibilty of the team for broken packages. My key point is, it is always an improvement to know the breakages sooner. And I don't expect lots of effort of the team in this direction. Minimal effort is just enough:
I think spending one more minute will not slow down the development of the project, and it is good for all. |
The team discussed the general issue at today's meeting. We have a few possible approaches in mind, each with positive arguments in favour. We are going to work on this a bit more before making a decision on changes for the future. |
We have decided to go with a main/dev split for |
We have moved ahead with the |
Brief outline of the enhancement
Recently some packages broke after a new
l3kernel
release had been out. Therefore I think it might be a good improvement to test more packages before publishing a newlatex2e
(orl3kernel
) release.Mr. Wright replied in lvjr/tabularray#474 (comment):
But after doing some experiments I think it is doable. Island of TeX provides weekly updated Docker images for latest full TeX Live. So we can run tests on them with GitHub Actions.
Step 0: Find out all
.sty
and.cls
files intex/latex
folder and compile them withpdflatex
on current TeX Live.Then add every package file which fails the compilation to an
ignorelist
. (If you want to do more you could also considertex/xelatex
andtex/lualatex
folders as well asxelatex
andlualatex
programs in the future.)We only need to do Step 0 once. Now every time a new latex release is out, we need to do the following two steps:
Step 1: Do tests similar to Step 0, but we exclude package files in
ignorelist
and record every success package file in apasslist
.Step 2: Install the new latex release to TeXLive Docker image. And this time we only test files in
passlist
. If a package file inpasslist
fails the test, we are almost sure that it is caused by the new latex release.The text was updated successfully, but these errors were encountered: