Re: Should a Guix package include documentation dependencies to be considered complete?
jgart writes: > Hi Guixers, > > For example, > > https://github.com/Abjad/abjad/blob/63520b2a00ef59f3302837f843d069c3946baa6c/docs/Makefile#L113 > > We have abjad packaged but we don't necessarily have all the > dependencies needed to build everything that abjad provides such as a > PDF document that it mentions in its project Makefile. > > Should we include the LaTeX dependencies in the abjad package? > > Should all Python packages include the required dependencies to build > documentation? > > We currently include all the dependencies to run the tests, why not do > the same for documentation building? > > Should we make it a requirement or goal to always package a given package's > "documentation-inputs"? > > There's another thread where I already talked on this topic with roptat > briefly. I'll find it and link it soon. > Is it just limited to the documentation files, or does it also include softwares needed to read them? -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Should a Guix package include documentation dependencies to be considered complete?
On 2022-12-07, jg...@dismail.de wrote: > We have abjad packaged but we don't necessarily have all the > dependencies needed to build everything that abjad provides such as a > PDF document that it mentions in its project Makefile. > > Should we include the LaTeX dependencies in the abjad package? > > Should all Python packages include the required dependencies to build > documentation? With my Reproducible Builds hat on... Some of the main remaining reproducibility issues in Debian are with documentation generation, notably .pdf and various non-determinism issues in sphinx, frequently used to generate documentation in various formats in python projects. I would hate to have a policy to always generate documentation if it makes Guix less reproducible... maybe putting the documentation into a separate output at least? While unreproducible documentation is unfortunate, it is not that same as, say, the kernel or important core libraries. I personally have a strong preference for formats that are largely readable as "plain" text (markdown, restructuredtext) to fancy formatting; you can just copy them into the package rather than having to transform them into some fancy format. I also get that that does not work for everyone... > We currently include all the dependencies to run the tests, why not do > the same for documentation building? > > Should we make it a requirement or goal to always package a given package's > "documentation-inputs"? Systematically and programatically being able to distinguish between "regular" inputs and test and documentation inputs sounds useful in a number off ways... my only worry would be when a particular input might shift from one category to another without noticing, and keeping track of those changes, and maybe cross building would be something to consider as well. But the advantages might outweigh the disadvantages. In Debian there is a concept of build profiles (e.g. nocheck, nodoc) which alter which dependencies are required to build the package. live well, vagrant signature.asc Description: PGP signature
Re: Should a Guix package include documentation dependencies to be considered complete?
> We currently include all the dependencies to run the tests, why not do > the same for documentation building? > > Should we make it a requirement or goal to always package a given package's > "documentation-inputs"? i also lack guidance on this. and i somewhat miss a "test-inputs" field to explicitly mark the dependencies that are only needed to run the tests. this often doubles the native-inputs dependencies of python packages. then the infrastructure could be smartened up to not require those dependencies when the tests are disabled for a package. it could serve as a temporary bandaid to fix/upgrade a package while there are some issues with the dependencies needed to run the tests. i guess same applies to documentation. some brainstorm follows: but what should be the way to control this for documentation? package arguments, like #:tests? #f for tests? or some way to mark some of the outputs as optional, and a way to request the optional outputs? how would the latter apply to tests, that have no package output? is the anomaly justified? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “To every man is given the key to the gates of heaven; the same key opens the gates of hell. And so it is with science.” — Richard Feynman (1918–1988)
Should a Guix package include documentation dependencies to be considered complete?
Hi Guixers, For example, https://github.com/Abjad/abjad/blob/63520b2a00ef59f3302837f843d069c3946baa6c/docs/Makefile#L113 We have abjad packaged but we don't necessarily have all the dependencies needed to build everything that abjad provides such as a PDF document that it mentions in its project Makefile. Should we include the LaTeX dependencies in the abjad package? Should all Python packages include the required dependencies to build documentation? We currently include all the dependencies to run the tests, why not do the same for documentation building? Should we make it a requirement or goal to always package a given package's "documentation-inputs"? There's another thread where I already talked on this topic with roptat briefly. I'll find it and link it soon.
Python Packaging Policy
Hi Guixers, What is our approach/policy to versioning Python packages? Since we get Python packages from PyPi in addition to other sources we are not necessarily trying to mirror PyPi. What is our policy then for updating Python packages in our Python library collection? Rolling release? Bleeding edge? LTS? Something else? How are we assuring that all Python libraries are working well together?
Re: Packaging big generated data files?
Denis 'GNUtoo' Carikli writes: > Is there any policies or past decisions of the Guix project on > packaging big generated data files? commit 183db725a4e7ef6a0ae5170bfa0967bb2eafded7 Author: Ricardo Wurmus Date: Tue May 15 12:55:27 2018 +0200 gnu: Add r-bsgenome-dmelanogaster-ucsc-dm6. * gnu/packages/bioconductor.scm (r-bsgenome-dmelanogaster-ucsc-dm6): New variable. HTH. Regards, Florian
Packaging big generated data files?
Hi, Is there any policies or past decisions of the Guix project on packaging big generated data files? I've added packages for software like kiwix-tools and navit that both work offline but that also need data files to be useful. Navit is a (car) navigation software that need maps. The maps can be generated from OpenStreetMap dumps with a tool available in Navit source code (maptool)[1] which is not packaged yet. Binary map files can also be downloaded directly from various sources. Right now the biggest file possible for such maps is about 47 GiB (for the whole planet). As for kiwix-tools, it can serve offline versions of websites like Wikipedia, and there too it needs files to work. The biggest file seems to be the complete version of English Wikipedia with scaled down pictures[2] and it takes about 89 GiB. I didn't look yet how these files were generated but I guess that they somehow can be generated from Wikipedia dumps. Packaging the binary files (without generating them) can be useful as it simplifies a lot the maintenance as one can just update the package version and checksum to update these. It also enables to keep the information (download URL, checksum, license) in one place and it enables easy reuse by Guix services and/or configuration files. If these files were generated in packages, it would also enable to tweak the data, for instance by adding height data in navit maps. As for kiwix compatible files, it would probably enable to decide when to make the snapshots or enable to package additional wikis (like the Libreplanet Wiki) or websites. The issue here is probably the size of the generated files: they are huge, so if they are packaged, they will most likely take significant resources in the Guix infrastructure. So what would be the way to go here? Would Guix accept patches to add packages for these files in Guix proper? If so, does it needs to be done like with the ZFS (kernel module) package where "#:substitutable? #f" is used to avoid redistributing package builds? Or are other ways better for such use cases? Note that so far I've only packaged locally only kiwix compatible files for various wikis by just downloading already prepared files, so I didn't look yet into navit maps or into generating all these files, so I might miss some details about generating them. References: --- [1]https://navit.readthedocs.io/en/latest/maps.html#processing-osm-maps-yourself [2]https://mirror.download.kiwix.org/zim/wikipedia/wikipedia_en_all_maxi_2022-05.zim Denis. pgpJ1igkoF_kj.pgp Description: OpenPGP digital signature
Re: Release progress, week 8
Hey Ludo, > fe563a87ad gnu: texinfo, info-reader: Do not run tests when cross-compiling. Wow, that's a lot of fixes! > Yesterday on IRC we discussed an installer crash received at > dump.guix.gnu.org. Did you or will you have time to look into it? Yes and I think that for some reason we are not detecting the installation device properly. However, as I cannot reproduce it, we would need to find someone kind enough to run an instrumented installer to understand this issue. We can also add a few traces to the syslog and fix this issue later on, depending on our schedule. Thanks, Mathieu
