Nils Gillmann writes: >> In addition, I notice that the license is GPL 2, but it seems the author >> did not specify whether "any later version" can be used. Therefore, I >> have listed this as gpl2, instead of gpl2+. > > The tails people (iirc it is a tails project, who are hosted on boum.org infra) > are generally okay with questions, I think you should ask about wether > it's GPL2 or GPL2+. > > We could also ask them about the state of MAT, as once upon a time they used to > include it in Tails. No idea if they stil do. I've sent an email to tails-dev@boum.org. I Cc'd you on it. I wasn't sure if the people of the tails-dev@boum.org email list would appreciate it if I arranged for their replies to automatically be recorded in our bug tracker, so I opted not to Cc this bug report on the email. We'll see what they say! >> +;; TODO: Add inputs for PDF support (e.g., Poppler, python-pdfrw). >> +;; TODO: Add inputs for GUI support (e.g., gi). >> +;; TODO: Fix some hard-coded paths. For example, get_datafile_path embeds >> +;; paths like "/usr/local/share/mat", which we should probably rewrite so that >> +;; they point to mat's output directory in the store. This specific example >> +;; causes "mat --list" to fail with an exception. > > I'm all for making it less hard for a package to get initially into Guix, but > shouldn't at least hardcoded paths that make an often used function(?) be fixed > first? On the other hand it is functional as you wrote. I've fixed this in the latest patch version (see attached)! While testing, I also discovered that the -b feature of the CLI tool does not work because of what appears to be a simple bug in MAT. I suppose I will report that upstream if they get back to me and they're still maintaining it. >> +(define-public python2-mat >> + (package >> + (name "python2-mat") > > Since people will expect this as "MAT" or "mat" and not "python2-mat", and to my > knowledge there is no python3 variant, we should name it just mat. On this topic, the precedent goes both ways, and I haven't seen any guidance yet on the email lists or in the manual. For example, see packages like awscli, python2-s3cmd, jupyter, and python-ansi2html. I think that if a package provides only an application, it makes sense to give it a name without the "python" or "python2" prefix. However, if the package provides a library, or it provides a library in addition to an application, then I think it's better to refer to it using the "python" or "python2" prefix, as described in the section titled "Python Modules" in the Guix manual. I also think this aligns with Guix's trend towards (usually) keeping libraries in the default "out" output of a package, rather than putting libraries in a separate "lib" output or a separate "devel" package. -- Chris