4 ms·

Why wget|dpkg and wget|sh instead of apt to download Pandoc and Calibre? You should be able to replace all this: !wget https://github.com/jgm/pandoc/relea

Why wget|dpkg and wget|sh instead of apt to download Pandoc and Calibre? You should be able to replace all this: !wget https://github.com/jgm/pandoc/releases/download/2.11.3.2/pandoc-2.11.3.2-1-amd64.deb !sudo dpkg -i pandoc-2.11.3.2-1-amd64.deb !apt install libgl1-mesa-glx -y !wget -q -O- https://download.calibre-ebook.com/linux-installer.sh | sudo sh /dev/stdin With simply this: !apt install pandoc calibre

stonesweep 6y ago
I use pandoc in a CD pipeline, the version in the repos is stale compared to upstream (normal, that's how it is) unless you're on a rolling distro like Arch. I have reported pandoc bugs and had them fixed (great dev team), pulling the latest single-DEB install (no deps, unlike the one in the Debian repo) and using it gets all the latest updates which matter to a process like this. In this particular case your needs to use the latest pandoc lead to the wget pull and install, which thanks to their DEB design is easy and clean to do in an ephemeral CI container.
- coreypreston 6y ago
  Do you have any more details about how you integrated Pandoc into your pipeline? A post or something?
  - stonesweep 6y ago
    Sure thing, it's pretty simple and straightforward I can post right here. In your CI/CD runner, you add a "before" script like so (Gitlab YAML example): image: debian:latest before_script: - bash myscript.sh Your myscript.sh can be as simple as four lines (one to install curl, it's not a default on Debian), example: apt-get -y install curl VERSION=$(curl -s "https://api.github.com/repos/jgm/pandoc/releases/latest" | grep -Po '"tag_name": "\K.*?(?=")') curl -sLo "pandoc-${VERSION}-1-amd64.deb" "https://github.com/jgm/pandoc/releases/download/${VERSION}/pandoc-${VERSION}-1-amd64.deb" apt-get -y install "./pandoc-${VERSION}-1-amd64.deb" The Github API used above has the nice default of listing the latest release as you see used there in the grep on the right, one could enhance that with `jq` for higher intelligence but this very simple setup is functional as a starting point to develop your own style.
sundarurfriend 6y ago
Calibre website strongly recommends downloading from their site instead of OS packages, mentioning that the packages are often out of date. And I've generally found this to be true - Calibre versions on package repos are often several versions behind, more than the usual "package maintainer trying to play catch up" differences. I'm usually averse to the wget|sh installs, but in this case it seems worth it. You can inspect the .sh file (which is really mostly Python code) before running it, just to not get into the bad habit of directly piping in code from the internet.
- progval 6y ago
  > You can inspect the .sh file That's not the issue. Installing software this way means you have no automatic updates in the future. It's fine if you re-run the install script on a regular basis (eg. by recreating containers) AND you don't pin versions But OP's instructions fail both: there is no mention of updates, and they pin the pandoc version.

stonesweep 6y ago

I use pandoc in a CD pipeline, the version in the repos is stale compared to upstream (normal, that's how it is) unless you're on a rolling distro like Arch. I have reported pandoc bugs and had them fixed (great dev team), pulling the latest single-DEB install (no deps, unlike the one in the Debian repo) and using it gets all the latest updates which matter to a process like this. In this particular case your needs to use the latest pandoc lead to the wget pull and install, which thanks to their DEB design is easy and clean to do in an ephemeral CI container.

coreypreston 6y ago
Do you have any more details about how you integrated Pandoc into your pipeline? A post or something?
- stonesweep 6y ago
  Sure thing, it's pretty simple and straightforward I can post right here. In your CI/CD runner, you add a "before" script like so (Gitlab YAML example): image: debian:latest before_script: - bash myscript.sh Your myscript.sh can be as simple as four lines (one to install curl, it's not a default on Debian), example: apt-get -y install curl VERSION=$(curl -s "https://api.github.com/repos/jgm/pandoc/releases/latest" | grep -Po '"tag_name": "\K.*?(?=")') curl -sLo "pandoc-${VERSION}-1-amd64.deb" "https://github.com/jgm/pandoc/releases/download/${VERSION}/pandoc-${VERSION}-1-amd64.deb" apt-get -y install "./pandoc-${VERSION}-1-amd64.deb" The Github API used above has the nice default of listing the latest release as you see used there in the grep on the right, one could enhance that with `jq` for higher intelligence but this very simple setup is functional as a starting point to develop your own style.

sundarurfriend 6y ago

Calibre website strongly recommends downloading from their site instead of OS packages, mentioning that the packages are often out of date. And I've generally found this to be true - Calibre versions on package repos are often several versions behind, more than the usual "package maintainer trying to play catch up" differences. I'm usually averse to the wget|sh installs, but in this case it seems worth it. You can inspect the .sh file (which is really mostly Python code) before running it, just to not get into the bad habit of directly piping in code from the internet.

progval 6y ago
> You can inspect the .sh file That's not the issue. Installing software this way means you have no automatic updates in the future. It's fine if you re-run the install script on a regular basis (eg. by recreating containers) AND you don't pin versions But OP's instructions fail both: there is no mention of updates, and they pin the pandoc version.