hive-nectar v0.1.3 - The "green" edition
Hey everyone,
I know it's only been a couple of days since the big v0.1.0 release of hive-nectar (and the two emergency patches that followed), but I couldn't leave well enough alone. Today, I'm happy to announce the release of version 0.1.3.
The main driver for this update was my personal obsession / OCD: I couldn't stop until the entire test suite was passing.
The Road to 100% Green
Getting a large, legacy codebase to a state where all tests pass without error is always a journey. The process uncovered a number of subtle bugs and areas that needed modernization. This effort resulted in a more stable and reliable library for everyone. A few of the key fixes include:
- Beneficiary Parsing: The function for parsing post beneficiaries was completely rewritten to correctly handle complex inputs, merge duplicate accounts, and properly distribute remaining percentages.
- API Call Resilience: Calls to the bridge API for fetching post lists now correctly respect the API's page size limits, preventing errors when requesting more than 20 posts at a time. Other calls were also updated to gracefully handle empty responses from the server.
- Connection Logic: The
is_connected()method was improved to more accurately reflect the connection state, preventing downstream errors that would occur when an RPC node was instantiated but not yet fully connected.
New Feature: HAF Integration
On top of the bug fixes, I've also added some rudimentary support for Hive Application Framework (HAF) endpoints. A new nectar.haf module has been added to the library to make these queries simple.
The first practical application of this is in fetching an account's reputation. When you now call Account("username").reputation(), the library will first attempt to get the most up-to-date reputation score directly from a HAF endpoint. If that fails, it gracefully falls back to the cached reputation value stored on the account object (25).
This release is another big step forward in modernizing hive-nectar, and I'm thrilled with the progress. The new version is now live on PyPI.
GitHub: https://github.com/TheCrazyGM/hive-nectar
DeepWiki: https://deepwiki.com/TheCrazyGM/hive-nectar
ReadTheDocs: https://hive-nectar.readthedocs.io
As always,
Michael Garcia a.k.a. TheCrazyGM
Your attention to detail is very welcome indeed, my friend, and congratulations on this notably-improved version. It's getting better and better! 😁🙏💚✨🤙
This is the first time I've noticed this project. I'll soon be looking at your repo to see if there is anything to learn from it. I'm interested to learn what made you choose to fork BEEM rather than starting from scratch or from something less bloated and a bit more suitable for integrated usage like lihghive.
When diving back into HIVE python code (I wrote the asyncsteem lib back in the early days) I looked at my old (Python 2) code, BEEM and lighthive, and after dismissing BEEM I gave lighthive a long thought and try before ending up starting from scratch myself. My own efforts are less general purpose ( aiohivebot ), and delayed because my main project (that I aim to incorporate) is about piggybagging (and eventualy integrating) hash based signatures, so quite a long way from usable, also because I'm not adding signing untill I can complete my stack and add both eliptic curve and hash based signatures at the same time.
So basicly my old python 2 code was too outdated (it was pure python 2, used twisted and used unthrottled communication with the nodes), beem was too synchonous, too bloated, using virtualy zero runtime python features that could make the codebase much leaner and massive the TDD focus felt just too much like an overengineered school project for what I felt should be a lean and mean lib. Lighthive was very good, with some async code under the hood, but my ideas about redundant multi-API-node async design just were too far from @emrebeyler's vission to try and fit it in.
I personaly considered BEEM a deadend road, lighthive a good general purpose replacement, and my own effort (eventualy) a specialized alternative for bots and L2 solutions unsuitable for commandline tools.
I would be interested to learn why you chose to fork from beem and not @emrebeyler's lighthive?
The reason it was chosen is I've been using in since way back in the Steem days, and a lot of our stuff was already using it. So I just found it easier to fix issues as they came up and make it work for me.
Now, I do plan on going over every piece of it, possibly rewriting entire parts, but I got used the way beem was laid out. In the end I will make it my own thing, and I may end up stripping much of it out.
I guess I was just comfortable with it, and wanted something that was 1:1 with how I got used to doing things. But I am no where near done tinkering.
RE: lighthive - It's not bad, but I have used it very little.
RE: starting from scratch - I actually do want to do something like that, but I think I'm going to aim for a Golang library instead (or possibly Rust if I can ever get used to it).