pyslow5 now updated to v1.2.0 (along with slow5lib) and works with the latest numpy 2.0.0 updates

Check out the release notes
We also added big-endian support, never thought we would need to do that 😅

Stellar work from
@hasindu2008 as always

https://github.com/hasindu2008/slow5lib/releases/tag/v1.2.0

Release slow5lib-v1.2.0 · hasindu2008/slow5lib

What's Changed slow5lib easy multi-thread API is no-longer beta and is fully documented now at https://hasindu2008.github.io/slow5lib/slow5_api/slow5_mt_api.html. Examples at here new low-level AP...

GitHub
@Psy_Fer_ @hasindu2008 The advantages of SLOW5 over fast5 were obvious. Given that POD5 has now become the standard output for ONT, how does SLOW5 compare? What are the potential advantages and reasons to adopt it? Thanks
@hasindu2008 @typeMAT12 I'd love to see people try and build old versions of pod5 in a few years 😅
@Psy_Fer_ @hasindu2008 Definitely true that ONT is unstable, in terms of versioning (both in the lab and computationally). It’s incredibly frustrating to develop and validate a method, only for all the kits, basecalling models and tools (eg shift from guppy to dorado), compute requirements (latest dorado incompatible with older Macs), and downstream tool compatibility (eg latest Clair3 models don’t play well with guppy now) to change every 6-12 months.
@Psy_Fer_ @hasindu2008 Are there any risks that ONT will make further changes that break your toolkit, and prevent longterm compatibility?

@typeMAT12 @Psy_Fer_

The good thing with slow5 is only the XYZ -> BLOW5 converter we have to fix everytime ONT does a breaking change to their file formats. Any tools that is written on top slow5 will not require to change. Because of this, we have to fix only the converter only, instead of fixing 100 tools separately :D

@typeMAT12 @Psy_Fer_

For instance when ONT moved to POD5,
We simply wrote the blue-crab converter to do pod5->slow5 converter.

All my tools and the scripts in our sequencing facility that uses slow5 did not have to undergo a single change,