Re: LaTeX packaging policy
Hi, On Sat, 24 Dec 2022 at 13:03, Josselin Poiret wrote: > While using a bit of LaTeX recently, I've noticed some packages don't > work "out-of-the-box", at least on LuaLaTeX, and need some additional > propagated inputs. Examples would be babel-french needing scalefnt, > fontspec needing luaotfload, or hyperref needing stringenc. Is there > any established policy for what propagated-inputs need to be included in > package definitions? Should we add some LaTeX specific packaging > guidelines in the manual, like for Python or Rust (the former is > outdated by the way, mentioning Python 2 packages). All the inputs are they required as propagated-inputs? Or only some? Maybe it could be worth to fix the broken packages (the examples above) and see if a pattern emerge for writing down a policy. Or maybe, we could propagate all the inputs since TeX can be considered as stable enough for minimizing the clash of versions. Cheers, simon
Re: LaTeX packaging policy
Nguyễn Gia Phong skribis: > On 2023-01-04 at 08:11+01:00, Reza Housseini wrote: >> What about size? Does [propagating all build inputs] >> not bloat up profile sizes? > > I'm new to Guix, but aren't both build inputs > and propagated build inputs required at run time? > IIUC the only difference is that the propagated ones' env > is, ehm, propagated all the way up instead of just > to the direct dependee. No, inputs are not necessarily available at run time. An input is kept at run time (as a “reference”) if and only if guix-daemon finds a reference to it in the build product. Ludo’.
Re: LaTeX packaging policy
On 2023-01-04 at 08:11+01:00, Reza Housseini wrote: > What about size? Does [propagating all build inputs] > not bloat up profile sizes? I'm new to Guix, but aren't both build inputs and propagated build inputs required at run time? IIUC the only difference is that the propagated ones' env is, ehm, propagated all the way up instead of just to the direct dependee.
Re: LaTeX packaging policy
Good question, maybe we should just do that. Thoughts? What about size? Does this not bloat up profile sizes? -- Reza Housseini This message is signed with my GnuPG key: C0F3 0812 9AF2 80F4 0830 C2C1 C375 C6AF 0512 5C52 OpenPGP_0xC375C6AF05125C52.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: LaTeX packaging policy
Nguyễn Gia Phong skribis: > On 2023-01-03 at 10:05+01:00, Ludovic Courtès wrote: >> But how difficult would it be to identify what needs to be propagated? > > Is there any practical reasons to not propagate all TeX packages? > For other language I suppose we need to avoid version clashing, > but in my experience TeX packages usually maintain a stable API. Good question, maybe we should just do that. Thoughts? Ludo’.
Re: LaTeX packaging policy
On 2023-01-03 at 10:05+01:00, Ludovic Courtès wrote: > But how difficult would it be to identify what needs to be propagated? Is there any practical reasons to not propagate all TeX packages? For other language I suppose we need to avoid version clashing, but in my experience TeX packages usually maintain a stable API.
Re: LaTeX packaging policy
Hello! Josselin Poiret skribis: > While using a bit of LaTeX recently, I've noticed some packages don't > work "out-of-the-box", at least on LuaLaTeX, and need some additional > propagated inputs. Examples would be babel-french needing scalefnt, > fontspec needing luaotfload, or hyperref needing stringenc. Is there > any established policy for what propagated-inputs need to be included in > package definitions? Should we add some LaTeX specific packaging > guidelines in the manual, like for Python or Rust (the former is > outdated by the way, mentioning Python 2 packages). I noticed the lack of propagated inputs for some packages. I don’t think there’s an established policy. Ideally, to mimic what’s done with other languages and to make things work out of the box, we’d propagate anything that’s needed. But how difficult would it be to identify what needs to be propagated? Thanks, Ludo’.
LaTeX packaging policy
Hi everyone, While using a bit of LaTeX recently, I've noticed some packages don't work "out-of-the-box", at least on LuaLaTeX, and need some additional propagated inputs. Examples would be babel-french needing scalefnt, fontspec needing luaotfload, or hyperref needing stringenc. Is there any established policy for what propagated-inputs need to be included in package definitions? Should we add some LaTeX specific packaging guidelines in the manual, like for Python or Rust (the former is outdated by the way, mentioning Python 2 packages). I can work on those if there's some sort of consensus, but just need some advice from more experienced LaTeX packagers. Best, -- Josselin Poiret
