strubbl / wallabago Goto Github PK

I tried to use wallabago while using go modules (I'm using go 1.13) and I could not use any version higher than v1.0.0.

The reason is that go modules only understand tags that start with the v. I tested it with a fork and it works smoothly when the release tag is, for example, v2.0.0 instead of 2.0.0: https://github.com/agarciamontoro/wallabago/releases/tag/v2.0.0

Is it possible to stick to this convention so that wallabago can be used with go modules? Thank you!

From the point of view of wallabako, the GetEntries function can sometimes silently fail. For example in this issue, I have found that when the machine running wallabako gets suspended for extended periods of time (while wallabako is running!), GetEntries can return an apparent success while still actually failing to do the request. In my use case, this means returning "0 unread entries" (the "zero value" of that field of course), which means all the files get removed! Nothing shows up in the logs, because fmt.Fprintf is used instead of (say) log.Fprintf either, so the error looks completely mysterious.

In general, this is an API design flaw that permeates the library: instead of printing errors on stderr with fmt, we should return errors like I proposed in #5. For example, in GetEntries instead of:

	fmt.Fprintf(os.Stderr, "getEntries: json unmarshal failed: %v\n", err)

we should:

            return e, fmt.Errorf("getEntries: json unmarshal failed: %v\n", err)

... or possible just:

 return e, err

Similarly, in that funciton bodyByteGetterFunc should be able to raise errors in the idiomatic golang way as well.

I understand this can be an annoying change to perform as it is somewhat far-ranging, but it seems important to uncover mistakes like the bug I have found...

Thanks!

I would need to set read status and similar settings through the API. This is not currently possible as we can only do GET requests. I would need to do PATCH requests. As a workaround, I have implemented a patch that allows me to generate new access tokens in #4 - but that's not ideal.

upstream finally implemented better oauth support (wallabag/wallabag#2800). the means we do not need to store the cleartext user password anymore nor use it in the API, starting with 2.3.0: the client secret strings are enough to get a token.

i am not sure how to handle this. should we break backwards compatibility with older releases? should we detect the API version and require the right configuration depending on the API?

i needed this for wallabako but figured here was actually where this was implemented.

would it be possible to release a binary on github or gitlab ?
it would sure help quickly testing it out, and maybe creating a package for Linux distros (Arch AUR)

I get this running wallabako now:

2018/03/20 16:53:30 failed to list entries in wallabag: json: cannot unmarshal string into Go struct field Range.startOffset of type int

The problem is that Wallabag 2.3.2 sends this in the annotation struct:

        "annotations": [
          {
            "user": "anarcat",
            "annotator_schema_version": "v1.0",
            "id": 7,
            "text": "wtf",
            "created_at": "2018-03-19T10:02:45-0400",
            "updated_at": "2018-03-19T10:02:45-0400",
            "quote": "“We can now create machines that can change what people think and what people do, and the machines can do that autonomously.”",
            "ranges": [
              {
                "start": "/div[2]/div[1]/p[10]",
                "startOffset": "112",
                "end": "/div[2]/div[1]/p[10]",
                "endOffset": "238"
              }
            ]
[...]

notice how start/end aren't actual integers anymore? not sure how to deal with such insanity, but I've done this to workaround the problem for now:

diff --git a/annotations.go b/annotations.go
index 76c94b0..2962f83 100644
--- a/annotations.go
+++ b/annotations.go
@@ -27,9 +27,9 @@ type Annotation struct {
 // Range represents the text borders of an annotation
 type Range struct {
 	End         string `json:"end"`
-	EndOffset   int    `json:"endOffset"`
+	EndOffset   string `json:"endOffset"`
 	Start       string `json:"start"`
-	StartOffset int    `json:"startOffset"`
+	StartOffset string `json:"startOffset"`
 }
 
 // GetAnnotations queries the API for all annotations of an article according to /api/annotations/ID

quick and dirty, but it works, probably because I don't use those anywhere...

hello again! :)

i was surprised to find an API change when my CI failed here... Turns out that GetEntries now needs a callback, which is fine, but i didn't expect such a change without a version number bump.

i encourage you to tag releases and use the semver.org standard for naming those versions. if there would have been a major (or even minor) version bump I would have been more careful before doing my own releases...