Release Plan

[Sekenre]

Sorry I've been quiet lately. I do have a rough plan for the next releases:

Release 4.2 by October:

• Last release supporting Python 2.7
• @waveform80 's C-Library

Release 4.3 by December (may slip depending on my workload):

• Drop Python 2.7
• Support for CBOR array tags

Edit: No need for a major version bump.

[agronholm]

Does the array tags support, or some other change, require bumping the major version?

[Sekenre]

Mostly to mark the break with Py 2.7 if that makes sense. Array tags is just the next feature I want to use for my own stuff.

[agronholm]

I'm not sure that the Python version requirement change should cause a major version bump. Using python_requires we can simply keep 2.7 users at the last compatible release while pushing out py3 only releases at the same time.

[Sekenre]

Ok sure.

[waveform80]

Looks good. Incidentally, on array tags, I had a shot at making a C version for that too (see arrays branch on https://github.com/waveform80/cbor2). Not complete yet - can't remember what state I left it in, but it might form the basis for something.

[waveform80]

can't remember what state I left it in, but it might form the basis for something.

Just had a quick skim of that branch: looks like I didn't get around to starting the C version, but the Python support for single-dim arrays is complete, along with encoding of multi-dim numpy arrays (but decoding isn't finished); includes support for all big/little endian variants specified in CBOR. If I get some time next week I might see if I can finish off the Python side of things (which should be quick), but I doubt I'll have time to start on the C side for the next few weeks.

[auscompgeek]

So the timeline in the issue description has completely lapsed… what's the plan?

[Sekenre]

Hi @auscompgeek Just got back from vacation. I'll be releasing 4.2 shortly. Some documentation fixes from others haven't made it in which is why I was reluctant to go ahead.

[Sekenre]

4.2.0 has just been released, source package only at the moment.

Next release will be documentation updates and improvements to the build process.

[justinmayer]

Thanks for the release, @Sekenre. I don't know whether the following deprecation notice should be addressed in a 4.2.x release, or whether it must wait until Python 2.7 support is dropped, but it would be nice to get this fixed in the near future:

/lib/python3.7/site-packages/cbor2/decoder.py:3
  /lib/python3.7/site-packages/cbor2/decoder.py:3: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
    from collections import Mapping

[agronholm]

Is there a plan to release binary wheels too? Do you need help with that?

[Sekenre]

Hi @justinmayer Yes that's my intention. It will be part of dropping 2.7 support

[Sekenre]

@agronholm I'm currently working on using the manylinux2010 docker image to build packages. Once I'm sure it's working I'll update the Travis configuration.

[agronholm]

That will only be enough to create Linux wheels. Travis does not have proper Python support for any other OS. I've recently learned to use Github Actions which could provide a decent way to build binary wheels on those operating systems too. It will take some tinkering but if you want, I could give it a try.

[Sekenre]

I would really appreciate it @agronholm thanks!

It might be worth setting up an account on https://test.pypi.org so we can upload potentially broken builds with impunity.

[agronholm]

I only now took notice of the changelog entries for 4.2.0 and it seems it contains backwards incompatible changes. This is not permissible according to semantic versioning; the major version number should have been bumped. I would have liked to discuss these privately but I could not find your contact information @Sekenre.

[kalcutter]

I have an implementation of CBOR array tags based on numpy which implements everything from RFC 8746. I can create a PR if this is something of interest. Do people think it is reasonable for this library to depend on numpy?

[agronholm]

Do people think it is reasonable for this library to depend on numpy

Absolutely not. We can add it to the documentation as an example extension, but having a huge dependency like numpy for a niche use case would be crazy.

[kalcutter]

Absolutely not. We can add it to the documentation as an example extension, but having a huge dependency like numpy for a niche use case would be crazy.

That was also my thought. 😁 But I just thought I would ask since there was mention of numpy above without any pushback.

[Sekenre]

I had been working on support for arrays haven't had time to finish, I can push it to my public repo for you to have a look at if you're keen to have a go?

[agronholm]

Clarifying my earlier comment: while a hard dependency on numpy is a no-no, having array support as an optional feature that depends on numpy would be fine in my books. @Sekenre is the maintainer though so he has the final say.

[kalcutter]

I had been working on support for arrays haven't had time to finish, I can push it to my public repo for you to have a look at if you're keen to have a go?

Yah, it would be helpful to see what others have done in this area. I looked at what @waveform80 started which depends on the python3 array module. I don't think relying on array is a workable solution since it has a very limited set of supported types (i.e. only non-fixed width types from C and no support for float16 and float128). Numpy, on the other hand could represent all multi-dimensional and typed arrays from CBOR.

The simplest way to add support for typed and multi-dimensional arrays would be to simply try to import and use numpy for them and if that fails fall back by returning CBORTag(...). Another possibility would be to introduce new types like MultiDimArray and TypedArray which support conversion to numpy arrays.

[Sekenre]

@kalcutter Have a look at https://github.com/Sekenre/cbor2/blob/pure_py_arrays/examples/array_codec.py I have not added multi dim array support, but it can be supported by new types as you say. The big advantage of array.array is that it does not copy memory it just acts as a view. it can also be passed to numpy.

[kalcutter]

Creating a numpy array with numpy.frombuffer also acts as a view and does not copy the memory.

[tulku]

Hi @Sekenre! I was looking for CBOR libraries that implement typed arrays, and found this issue. What is the current status of this development? Thanks!

[agronholm]

Let's perhaps continue the discussion on typed arrays in #231.