Jean Libète <[email protected]> writes: > I'm trying to get the Heroku CLI packaged for Guix. > > While the source code of the CLI is available at > https://github.com/heroku/cli, I find that the state of JavaScript in > Guix is still such that I'm not able to get a working package > together. That said, they also offer tarballs of a "pre-built" > version. > > I put that in quotes as, from what I can tell of the packages files, > it's largely Python and JavaScript files with a bash script that uses > Node to run them. > > As it's mostly interpreted files/scripts, would this be acceptable for > the base of a package in Guix? I put together something which works: > > (define-public heroku-cli > (package > (name "heroku-cli") > (version "10.15.0") > (source (origin > (method url-fetch) > (uri (string-append "https://cli-assets.heroku.com/versions/"; > version > "/4bb523c/heroku-v" version > "-4bb523c-linux-x64.tar.gz")) > (sha256 (base32 > > "0sf4lbscd5655krxlv998gmqrvdwqyvfcsyzkw1plq77hv6qil25")))) > (build-system copy-build-system) > (inputs (list node python)) > (arguments > `(#:phases > (modify-phases %standard-phases > (add-after 'unpack 'fix-interpreters > (lambda* (#:key inputs #:allow-other-keys) > (substitute* "bin/heroku" > ;; remove checking for a node executable > (("if \\[ -x \"\\$[(]command -v > \"\\$XDG_DATA_HOME/oclif/node/node-custom\"[)]\" ]; then") > "if [ 0 ]; then") > ((" NODE=\"\\$XDG_DATA_HOME/oclif/node/node-custom\"") > " echo \"who cares\" > /dev/null 2>&1") > ((" elif \\[ -x \"\\$[(]command -v \"\\$DIR/node\"[)]\" ]; > then") > "") > ((" NODE=\"\\$DIR/node\"") > "") > ((" elif \\[ -x \"\\$[(]command -v > \"\\$XDG_DATA_HOME/oclif/node/node-[0-9]*\\.[0-9]*\\.[0-9]*\"[)]\" ]; then") > "") > ((" > NODE=\"\\$XDG_DATA_HOME/oclif/node/node-[0-9]*\\.[0-9]*\\.[0-9]*\"") > "") > ((" elif \\[ -x \"\\$[(]command -v node[)]\" ]; then") > "") > ((" NODE=node") > "") > ;; sub. the guix package's path for the executable > (("\"\\$NODE\"") (search-input-file inputs "bin/node"))) > > (delete-file "bin/node")))))) > (home-page "https://devcenter.heroku.com/articles/heroku-cli";) > (synopsis "CLI tool to manage Heroku apps from the command line") > (description "The Heroku Command Line Interface (CLI) is used to manage > Heroku apps from the command line. With it, you can create and manage Heroku > apps directly from the terminal.") > (license license:isc))) > > I swap out the Node executable that the tarball offers with an > executable from a Node package in Guix and that's pretty much all of > the compiled executables from the tarball, from what I can see and > find during running the provided bash script. > > While this points to the x64 tarball, I'm not sure that the > architecture entirely matters; I suspect it's mostly to get the > executable Node binary correct which is rendered moot as it would be > using the Guix Node package's executable, instead. > > I'm running a x86_64 machine and changed the source tarball URL to > their arm64 one and it's running equally fine. > > Jean
Hi Jean, Thanks for contributing to Guix. I think the first thing you can focus on is the source. The main Guix channel has strict requirements about fully libre source, no source binaries, and avoiding bundling as much as possible. That is bundling dependencies of a package in its source. In your case, I’ve downloaded your package’s source and here’s my thoughts: - node_modules is a directory for bundled dependencies, they need to be removed in the snippet of the origin. See the manual page '(guix) Snippets versus Phases'. - The dependencies in node_modules may or may not be free software, their licenses should be checked. - The bin directory should be deleted, also in a snippet (although its acceptable that you did it in a phase). These requirements will probably make it much harder for you to produce a working package. Surely from the same reasons why the Javascript ecosystem is not more developed in Guix. However, if you feel that you want to improve that situation. I encourage you to try it anyways! You can get more information about this from the JavaScript team (see (guix) Teams). Also look into `guix import npm-binary` and `node-build-system`. As a first step, I’m sure you still want the package without having to go through all this trouble (especially since it works!). You can try keeping the bundling, while still checking for the right licenses in dependencies then contribute your package to a community channel (see https://toys.whereis.social/channels). Hope that’s clear, I’m not too knowledgeable on Javascript in Guix specifically so I might be wrong on some specifics. Good day! Noé
signature.asc
Description: PGP signature
