Arch Linux User Repository

Note! Papis skips integration tests for certain optdeps if they aren't installed[1]. Since checkdeps should contain all the dependencies to check a standard build, I've added these to checkdepends.

If you're not planning on installing these optdeps and want to skip these specific tests, feel free to comment out the relevant lines in the checkdepends array. (This incidentally also goes for the multiple dependencies for the mypy tests, if they bother people).

The relevant dependencies at this time are: python-jinja, python-markdownify, python-whoosh

[1] - https://github.com/papis/papis/issues/776#issuecomment-1991874151

@m040601 Sorry for the delay in answering. Given the drift in dependencies since the last version, I think I'll wait to adopt the package until the next release, if no one else picks it up by then. It shouldn't be too much of a burden, just freezing a version of the -git PKGBUILD upon each release.

You may have noticed I've adopted python-doi and python-habanero. I had forgotten you pointed it out to me, so this was a fortunate accident (this is also part of why I didn't adopt python-arxiv2bib, the other being that it's not a dependency of papis-git.)

Thanks for the heads' up and for keeping me posted!

@gesh:

Jp-Ellis just abandoned the "papis" PKGBUILD, https://aur.archlinux.org/packages/papis.

Would you like to adopt it ? That would be great if you could.

I personally dont have the skills to this task. But I can of course help with testing and keeping a close watch.

• python-arxiv2bib
• python-doi
• python-habanero

were also abandoned.

Yeah, https://github.com/papis/papis/pull/607 changed over to pyprojecct and I haven't yet had time (probably won't for next week or two either) to update it. Thanks for the report, it'll make it easier when I do get arouund to it!

flake8 test was failing. Although max-line-length = 88 was set on pyproject.toml flake8 kept on throwing the E501: line too long (82>79).

Learned from vscode-flake8 that python-flake8-pyproject was required for flake8 to read from pyproject.toml

After installing it flake8 succeeded.

Is this just my issue or is someone else facing the same? flake8 - 1:7.0.0-1

Note! Papis skips integration tests for certain optdeps if they aren't installed[1]. Since checkdeps should contain all the dependencies to check a standard build, I've added these to checkdepends.

If you're not planning on installing these optdeps and want to skip these specific tests, feel free to comment out the relevant lines in the checkdepends array. (This incidentally also goes for the multiple dependencies for the mypy tests, if they bother people).

The relevant dependencies at this time are: python-jinja, python-markdownify, python-whoosh

[1] - https://github.com/papis/papis/issues/776#issuecomment-1991874151

@gesh

Thanks for the detailed clarification. As an AUR end user, it's very nice to know that you take this "job" serious. And make an effort to at least check out what the "papis" PKGBUILD is doing.

I left a notice there, so that the "papis" PKGBUILD" maintainers can be aware of that clarification and choices.

Hope you guys can collaborate and share work.

  • Not sure what your complaint is in re optdeps -- my original comment was iirc in re the optdepends all being written
    in one line, not much more.

Yeah. My fault, just forget it. My misreading. I saw the word "break" and got that wrong. I misread the sentence and was "afraid" of optional stuff being force pushed.

... optdeps like the scihub and libgen integration ...

And html. And also "zotero" integration.

All my talk about this is because I realized many of these are reallly "killer" addons for "papis". But they need to be well maintained and monitored on the AUR.

The "zotero" integration for example, is called "zotero" but can do much more than just deal with zotero import/export.

"papis zotero serve"

It is a little buried in the docs, but it lets you press the extension button in Firefox, and have your bib entry in the Papis database, completely bypassing Zotero. It's not quite evident from the name that it can do that. Zotero (the GUI, the sqlited db app) is irrelevant in that case. Only the "connector" Zotere firefox extension matters and does the astonishing heavy work of pulling structured information from thousands of different kinds of webpages as a ready made bib entry. That will directly land into your nice papis yaml file.

I really should put this stuff in the Arch wiki. I think not many people are aware.

The other thing with these papis "scripts" and extensions is that they dont get the same attention as the main repo by the papis devs themselves and lag many commits behind.

That might also be understandable in the case of 'libgen' and 'scihub' because of eventual legal issues. But that's also why I want to make sure that stuff in the AUR does get monitored regurlarly.

  • What breakage have you seen that you say

    This is not the easiest PKGBUILD to maintain. It breaks easly.

I basically meant to say that because of its necessary many dependencies on the AUR, the chances of one of them being out of date or unmaintained are higher. Not "papis" PKGBUILD itself fault. But it still affects it. I see this a lot with other python tools on the AUR.

So, thank again for the work in the PKGBUILD.

That's also why i really hope that one day one of the Arch official maintainers could adopt this tool. I've been following it and others (cobib, pubs) for some years now.

But only now did "papis" start to "click" for me. Because it is thought from the ground up to integrate well with others. It has seen a tremendous amount of cumulative work in the last years.

Would be usefull for so many people in Arch doing bib management. It is a really well maintained, moving forward, underrated project in my opinion. But I guess not many people are aware of it. And Zotero "steals" a lot of attention.

  • While you can install plugins via pip, I'd recommend against mixing vendoring options like that

I did not say 'pip'. I said 'pipx'. I never use neither 'pip' , nor 'pip --user'.

But pipx is a different beast.Is an interesting "clean" solution for those cases where that rare AUR PKGBUILD is hopelessly abandonedd unmaitained , and you do need the tool. It's more for "little cli" tools and less for "little libs". So it works for papis scihub/libgen, but not for papis zotero.

Thanks for the comments, it's always great to hear feedback!

So a few notes. As you say, the occurence of v0.14 in the changelog is misleading -- upstream seems to have allocated a version number for it immediately after releasing v0.13 https://github.com/papis/papis/commit/6b3a47e07cda3b9d69d77f3d1ce80cff6a3001eb

Next, the differences in license are correct on the -git side, see RFC0016.

Indeed, the non-git package is also pulling sources from pythonhosted.org, when RFC0020 recommends using upstream sources directly (in this case, presumably v0.13).

As for the more substantial differences:

• makedepends are standard for a PEP517 git package. IIRC the python-sphinx-click dep is for building the docs, but am unsure.

• The arxiv difference is due to a dep change that hasn't been released yet

• Don't know where the non-git version got its certifi dep from, can't find it in the git history

• Not sure what your complaint is in re optdeps -- my original comment was iirc in re the optdepends all being written in one line, not much more. As for additional optdeps like the scihub and libgen integration, they aren't and shouldn't be strict dependencies, hence why they occur in optdepends. Don't see anything in depends that can be made optional, so I'm unsure what you want changed. And I don't see what optdepends you would like added -- indeed, we have more of the optdepends documented than the non-git papis.

• While you can install plugins via pip, I'd recommend against mixing vendoring options like that. Just keeping track of which plugin comes from where is already a headache, if you then need to teach pip and pacman about dependencies each has installed you're in for unfun times.

• In re tests -- if you don't want to run tests, just pass --nocheck to makepkg (note that the build is pretty fast, it's mostly the tests that take a while. Though even that isn't that long -- have seen worse (eg Haskell builds)). If you do this, would recommend against just blindly invoking makepkg -s, because that'll also pull in the checkdepends. However, in general -git packages build directly off HEAD, so having this extra sanity check helps make sure you won't break your system before installing the package.

• What breakage have you seen that you say

This is not the easiest PKGBUILD to maintain. It breaks easly.

@m040601, thanks for the comments. @gesh has helped with updating the PKGBUILD, so that it's now in a much better state. Some responses to what you've said:

Also might want to break up the optdeps line. Yes. Please do this. Dont force optional dependencies as mandatory.

This was never about having these mandatory, but rather that there was a really long line there before, and how it's nicely split up over multiple lines. And yes, you're right there are more optdepends in papis-git than in papis. These could be added to the papis package also.

'python-arxiv2bib' │ 'python-arxiv'

Papis moved from arxiv2bib towards arxiv.py (I think because the former is unmaintained), which is why these are different. Once 0.14 is released the papis package should change this also.

license=('GPL') │ license=('GPL-3.0-or-later')

I think the latter is more correct, so that would also be a way that the papis PKGBUILD could be improved.

I was comparing the PKGBUILD, "papis" with this PKGBUILD "papis" and noticed these differences,

papis,

First Submitted: 2018-08-13 20:42 (UTC)

papis-git

First Submitted: 2020-12-29 06:22 (UTC)

A small one,

  license=('GPL')                                            │  license=('GPL-3.0-or-later')

These are only in "papis-git"

  -----------------------------------------------------------│  makedepends=('git'
  -----------------------------------------------------------│      'python-build'
  -----------------------------------------------------------│      'python-installer'
  -----------------------------------------------------------│      'python-wheel'
  -----------------------------------------------------------│      'python-sphinx-click'
  -----------------------------------------------------------│      )

These I dont understand why the difference

           'python-arxiv2bib'                                │           'python-arxiv'

These choices are also different.

  optdepends=(                                               │  optdepends=(
    'papis-rofi: integration with rofi'                      │      'fzf: fzf picker'
    'python-whoosh'                                          │      'papis-rofi: integration with rofi'
  -----------------------------------------------------------│      'papis-zotero: imports from zotero'
  -----------------------------------------------------------│      'pdfjs: pdf reader in the web app'
  -----------------------------------------------------------│      'python-jinja: jinja formatting'
  -----------------------------------------------------------│      'python-whoosh: whoosh database backend'

Another thing I noticed is that "papis-git" takes a huge time to complete the build, with lots of tests in the middle, compared to "papis".

This is not the easiest PKGBUILD to maintain. It breaks easly. There is already a not yet released papis v0.14 with loooootss of changes listed on the CHANGELOG.

Would be nice if the maintainers of these two PKGBUILD's "papis" and "papis-git" collaborated and shared the maintanence of both PKGBUILDS.

These would avoid reduplicating work, and would provide more pairs of eyes watching this very usefull tool.

With enough votes and concentrated effort this might even one day turn into an official Arch package.

gesh commented on 2023-11-12 13:58 (UTC) (edited on 2023-11-12 16:36 (UTC) by gesh)

Might want to add an optdep on https://pypi.org/project/papis-scihub/, am packaging it now. 

(E: packaged, at https://aur.archlinux.org/packages/python-papis-scihub-git)

The pypi.org repo and the repo you used for that scihub PKGBUILD dont match. I left some comments there.

Also might want to break up the optdeps line.

Yes. Please do this. Dont force optional dependencies as mandatory.

All these papis extras, scihub, libgen, etc are subject to constant change and breakage. No need to complicate the papis PKGBUILD more.

These extras are also possible to install directly from the pypi with "pipx install ...". A very clean option, that isolates things and doesnt pollute your system.