Building fails

[jkramer]

cpanm At fails due to failing tests because of "unrecognised parameters", see build.log for the complete output/build log.

[sanko]

Yeah, the API was changing faster than I felt like keeping up with this past spring. Checking now, and it's slowed down a lot but there's a ton of major parts being designed and redesigned by the lead devs even now: https://github.com/bluesky-social/atproto/branches/active

[jkramer]

That sounds annoying, wouldn't that break all other clients all the time as well? I don't wanna get too deep into atproto, I'm mostly interested in using your Bluesky module built on top to post some simple automated status updates. Do you think there's a way to make that work with a little hack or something, or are the API changes too profound for a quick workaround?

[sanko]

No, it wouldn't. It's perl's new class system choking on unknown parameters. I was looking at one of two "solutions" a few months ago: generate classes dynamically (which I'm not sure is possible yet) by mirroring the latest versions of lexicons, or adding a filter between the JSON decoder and all constructors. I hate both of those ideas.

Way back when, I saw a few clients were bundling a snapshot of lexicons and generating code based on them but even if I'd done that, the module would have started failing within a month according to the scheduled Github Action because they added emailAuthFactor to login responses. If I'd used bless instead, everything would be fine but I only wrote At.pm to try out classes.

I would be amazing if atproto was versioned and there was a stable, production type backend I could count on...

[sanko]

Well, I tried to find out if this would always be fatal in future releases of perl (Perl-Apollo/Corinna#110) and was told to "grin and bear it." I honestly don't think the designer(s) of perlclass understood what I was looking for and started handing out strange advice and warnings that made little sense even after I provided code examples to further clarify what I was asking.

Anyway, that's perl for you and above my pay grade so I'll just swap out object systems.

Bluesky is making the switch from their app password scheme to OAuth (bluesky-social/atproto#2656) so I'll need to do some heavy tinkering anyway.

[sanko]

Okay, I'm considering this (finally) resolved (soon). At.pm is now just a wrapper around an HTTP client that does requests, keeps session (eventually OAuth but that'll require extra steps for end users willing to put their own client metadata online somewhere according to https://atproto.com/specs/oauth#clients) and AT protocol rate limit data. I'm bundling raw lexicons and if a known lexicon is expected from a request, the content is coerced into a plain blessed object. Until I start messing with subscriptions to firehose type feeds, At.pm will not need to be updated because you can direct it to a directory with updated lexicons. At.pm deals with the technical side of the protocol which isn't specific to Bluesky. If you know what you're doing, you could easily write clients just using At.pm.

A client for Bluesky will be a different dist and wrap a lot of basic social network type stuff in a simple API.