Package Details: stapler 1.0.0-4

Git Clone URL: https://aur.archlinux.org/stapler.git (read-only, click to copy)
Package Base: stapler
Description: A small utility making use of the pypdf library to provide a (somewhat) lighter alternative to pdftk
Upstream URL: https://github.com/hellerbarde/stapler
Licenses: BSD
Conflicts: stapler-git
Submitter: biginoz
Maintainer: None
Last Packager: PhCl
Votes: 89
Popularity: 0.000000
First Submitted: 2010-08-26 17:32 (UTC)
Last Updated: 2020-08-27 11:31 (UTC)

Pinned Comments

PhCl commented on 2020-12-09 17:08 (UTC)

As python 3.8 was replaced by python 3.9, you could run into the following error:

Traceback (most recent call last):
  File "/usr/bin/stapler", line 5, in <module>
    from staplelib import main
ModuleNotFoundError: No module named 'staplelib'

To solve it, rebuild "python-pypdf2" and then "stapler". Then the directories for Python 3.9 should exist.

Latest Comments

1 2 3 4 Next › Last »

m040601 commented on 2021-07-20 15:39 (UTC) (edited on 2021-07-21 18:11 (UTC) by m040601)

This is a very usefull tool and apparently gets a lot of votes too. Thanks to everyone involved in providing these very usefull python pdf tools.

Stapler doesnt get many github commits (last one are from more than one year ago). And it can be a lot of trouble work to maintain the PKGBUILD due to the dependency on python-pypdf2.

Just want to chime in and suggest an alternative than may also be interesting to the same maintainers and users of this PKGBUILD.

captn3m0/pystitcher: pystitcher stitches your PDF files together, generating nice customizable bookmarks for you using a declarative markdown file as input

  • It seems polished and provides the same stapling/stiching functionality.

  • also published on pypi

  • it dependes not on pypdf2, but pypd3

Pypdf3 seems better maintained. sfneal/PyPDF3: A utility to read and write PDFs with Python , which is also on pypi . https://pypi.org/project/PyPDF3/

Pypdf3 is already on AUR, https://aur.archlinux.org/packages/python-pypdf3

Pypdf2 last commits are from 2018.

I did a quick test and it seems to work as it says on the can:

It seems to work perfectly with:

pipx install pystitcher

or

python -m venv testing_pystitcher

cd ./testing_pystitcher

source bin/activate

pip install pypdf3

pip install pystitcher


PhCl commented on 2020-12-09 17:08 (UTC)

As python 3.8 was replaced by python 3.9, you could run into the following error:

Traceback (most recent call last):
  File "/usr/bin/stapler", line 5, in <module>
    from staplelib import main
ModuleNotFoundError: No module named 'staplelib'

To solve it, rebuild "python-pypdf2" and then "stapler". Then the directories for Python 3.9 should exist.

PhCl commented on 2020-08-27 11:33 (UTC)

@ganymede: Thanks, added makedepends "python-pip". @rcrath: Not sure how it can happen, but I changed it to "rm -f" for now, so it should ignore the error if "/usr/bin/pdf-stapler" does not exist.

rcrath commented on 2020-08-24 21:22 (UTC)

update fails with

Installing collected packages: stapler
Successfully installed stapler-1.0.0
rm: cannot remove '/run/media/rich/8TbSeagate/yay/stapler/pkg/stapler/usr/bin/pdf-stapler': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...
error making: %!s(func() string=0x55b0858a3410)

ganymede commented on 2020-08-22 18:07 (UTC)

Thanks for the change. It introduces a dependency on pip, so please add 'python-pip' to makedepends (this package is only optional for python, therefore it's not necessarily installed).

PhCl commented on 2020-08-19 19:25 (UTC)

Alright, unless someone can bring up a good reason against it, I'll change it on the weekend.

pigmonkey commented on 2020-08-18 19:05 (UTC)

I also do not have a strong preference, but the stapler-git structure feels slightly more appropriate to me.

PhCl commented on 2020-08-18 18:49 (UTC)

@m040601 Hi, I adopted the project, so I can only speculate for the reasons of choosing /opt. According to https://wiki.archlinux.org/index.php/Arch_package_guidelines#Directories, /opt should be used for "Large self-contained packages".

It is not large, but arguably self-contained. Or is it a use case to use the library, not just the executable? (I only use the /usr/bin/stapler executable.)

I don't have a strong opinion for either way. As m040601 pointed out, the stapler-git shows how it can be done, so it should not be hard. If it is a better structure, I can change it.