Xaper concept/usage scenarios (was: Immediate exception on simple attempt to add a file)

[pfalcon]

Running 7471e67773b3939852221c5628da63bd32522b5d from https://gitlab.com/jrollins/xapers:

$ python3 -m xapers add -f 1960\ Recursive\ Programming\ -\ Dijkstra.pdf -i
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/mnt/hdd/projects-3rdparty/Tagging/xapers/xapers/__main__.py", line 1009, in <module>
    main()
  File "/mnt/hdd/projects-3rdparty/Tagging/xapers/xapers/__main__.py", line 1005, in main
    args.func(parser, args)
  File "/mnt/hdd/projects-3rdparty/Tagging/xapers/xapers/__main__.py", line 249, in cmd_add
    args.tags = args.tags.split(',')
AttributeError: 'NoneType' object has no attribute 'split'

[pfalcon]

Not getting much better with adding -t switch:

$ python3 -m xapers add -f 1960\ Recursive\ Programming\ -\ Dijkstra.pdf -t foo
Adding file... done.
Adding tags... done.
Syncing document... done.
 Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/mnt/hdd/projects-3rdparty/Tagging/xapers/xapers/__main__.py", line 1009, in <module>
    main()
  File "/mnt/hdd/projects-3rdparty/Tagging/xapers/xapers/__main__.py", line 1005, in main
    args.func(parser, args)
  File "/mnt/hdd/projects-3rdparty/Tagging/xapers/xapers/__main__.py", line 362, in cmd_add
    db.close()
AttributeError: 'Database' object has no attribute 'close'

(Default Python3.8 on Ubuntu 20.04).

[jrollins]

@pfalcon Thank you so much for the bug reports. I'm very encouraged by your interest.

Just FYI, the head of master is not stable and is the head of active development. I'm aware of these issues, and have been trying to get back to addressing them. If you're playing with xapers as a new user, please test with the latest tag (0.9). Thanks!

But also thanks for these reports, and I'll hopefully get to addressing them asap.

[jrollins]

Also I believe xapers 0.8.2 is in Ubuntu.

[pfalcon]

Thanks for the response!

please test with the latest tag (0.9)

Interesting, because https://gitlab.com/jrollins/xapers/-/blob/master/xapers/version.py still contains 0.8.2. And 0.8.2 is 3+ years old. No way a hacker would start with a 3-years old unfinished project, if 0.5-years old unfinished version exists ;-).

If you're playing with xapers as a new user

Well, I'm playing with it as an author of a similar project (https://github.com/pfalcon/papersman), which was started much later than xapers, so I would have duplicated effort by starting my project, and duplicating effort is one of the "mortal sins" of FOSS, and I don't want to be a sinner. So, I either look to contribute to the "better" project (or fork it, if it's not possible), or if it's not really "better", then with clean conscience continue digging my own hole. In this regard, I was looking for https://github.com/jrollins/xapers/issues/10, and seems it would be better to add it to my little piece.

If my notes (structured as the issue reports) are useful to the project, I'm glad. Otherwise, they are just those - copy of notes on "why I can't use xapers", which I gotta keep in my personal archive, to present to authorities at the last judgement, in an attempt to whitewash myself ;-).

[jrollins]

I would certainly welcome any development help. I hope xapers is useful for you, or that it can be extended to meet your needs (rather than forking or starting a similar project). But I acknowledge that it's not a fully polished project and still has work to do. I'm the only developer, and I do plan on continuing to improve it. In the meantime, it is useable in it's current state (I use it as part of my daily workflow).

[pfalcon]

But I acknowledge that it's not a fully polished project and still has work to do.

That's expected for most open-source software out there (well, for most software in general).

In the meantime, it is useable in it's current state

Definitely, but apparently, not for all workflows. Then the questions are: a) is it supposed to support "any" workflow, or just a "particular" workflow; b) how users could get better idea which particular workflow is supported (extra points for making it clear which workflows aren't supported).

(I use it as part of my daily workflow).

That's great to hear. Because I have to admit that with my tool, I don't really use it daily. I use it in "waves" (good example - I started writing it in the summer, because I was lying on a beach reading papers on my ebook, and had a need to categorize them afterwards quickly and efficiently; now in the winter, I thrash my keyboard writing code and don't have time for reading - until yesterday, when I read one, and want to record it, and take that as an excuse to look into xapers).

And I give that detailed use-scenario example, because I got a feeling that xapers in particular might have been developed as a thesis preparation tool, hence all these requirements for entering DOI together with the doc. Then it's common situation that when people graduate, they no longer need such tools, and they go unmaintained. "Focused on particular usage scenario" and "went unmaintained" is a common situation with such tools (I surveyed the landscape before starting to write mine, and there were definitely a few to see, and skip; again, I'm actually amazed that I managed to miss xapers then, and even now had troubles rediscovering it, https://github.com/jrollins/xapers/issues/6).

I would certainly welcome any development help. I'm the only developer, and I do plan on continuing to improve it.

It's familiar situation, for example, I'm the only developer of my "papersman" tool. And I don't expect that to change. But I expect myself to understand why I develop my own tool, why I can't use an existing tool, and why it's impractical to cooperate, and more practical to keep digging one's own hole. Again, I consider that information very important, more important than "development" per se (as it's deciding in what direction "development" goes at all). I don't know if other authors of similar software would find such information/discussion useful, but again, I do, so for as long as there's conversation, I'm happy to keep it up from my side.