Merging v2?

[boukeversteegh]

Hi all!

Hope you are all doing great @nat-n @danielgtaylor @abn

I see v2 is still in beta and not merged to master... are we not going to merge this? I think at some point it must be considered that if we don't merge that branch, it will become stale and abandoned. A lot of work was put in it, by me and others, and many recurring issues were fixed in v2, it would be a shame to let it go to waste.

I'm not up to date with current issues, and unfortunately I don't have time to get back on board, but unless there are strong reasons to maintain 2 parallel versions (where v1 is primary and v2 unsupported), I would recommend a merge. V1 can still be accessible if users are missing it.

Cheers, Bouke

[nat-n]

Hi @boukeversteegh,

As far as branches are concerned, 2.x follows master, and all development effort has gone towards 2.x, so I think we're alright there.

That said, there hasn't been a lot of maintainer bandwidth available in the last few months since the v2.0.0b3 release :(

It would be nice to have a proper release of 2.0.0 at some point; in my mind there are still a few breaking changes that would be good to get in before that, particularly:

• Enum prefix stripping Enum Prefix is not stripped #174
• Generation of nested enums Naming collision with nested enums #212
• Support for optional proto3 support for optional #229
• Making all service/client generation and grpclib dependency optional Option for generating code without async? #20
• maybe some others tracked here: https://github.com/danielgtaylor/python-betterproto/milestone/4

Unfortunately I don't know when I'll next have time to contribute much, so maybe it would be best to create a 2.0.0 release sooner (ideally with a few bug fixes, concerning newer features e.g. #245 #240 #235), accepting that more major version changes will be required in future.

[terax6669]

Been using V2 for a while and it's... almost ready in my opinion.

The only 2 problems I'm having are:

1. Forced case conversion during protoc compilation, but I believe that's also the case in v1?
2. I have an example of proto that is not parsing correctly. When attempting to save as bytes one of the fields flips from 9 to 1. Due to the nature of the project I cannot share any details online, but when the maintainers are gonna get to finalizing v2 release I'm willing to share the data privately.

[Gobot1234]

Been using V2 for a while and it's... almost ready in my opinion.

The only 2 problems I'm having are:

1. Forced case conversion during protoc compilation, but I believe that's also the case in v1?

2. I have an example of proto that is not parsing correctly. When attempting to save as bytes one of the fields flips from 9 to 1. Due to the nature of the project I cannot share any details online, but when the maintainers are gonna get to finalizing v2 release I'm willing to share the data privately.

Could you create a code snippet that can show this behaviour (it doesn't need to include the details of the stuff you can't show) and submit a issue?

[fundthmcalculus]

Hi @nat-n I'm currently using V2 for work with my company Trinsic.id. I'd love to help maintain the package.

[lazytype]

@kalzoo @Gobot1234 could a v2.0.0b4 be tagged and released to PyPI? It would help immediately unblock the ability to use Python 3.10

[fundthmcalculus]

@lazytype in theory you can pip install from the source on github, but that doesn't fix the underlying problem. @danielgtaylor thoughts?

[Gobot1234]

@lazytype I've setup #307 for the next release.

[efokschaner]

If I made a pr for #287 is there a chance it could make it in to 2.0 ?

[Gobot1234]

If I made a pr for #287 is there a chance it could make it in to 2.0 ?

Absolutely

[FHTMitchell]

Is there any update on when we think 2.0 will be released? I'm excited to use servers and #287

[terax6669]

Could you create a code snippet that can show this behaviour (it doesn't need to include the details of the stuff you can't show) and submit a issue?

Still a problem with 2.0.0b5

with open('example_raw.proto', 'rb') as f:
	tmp = Example().parse(f.read())
with open('example_parsed.proto', 'wb') as f:
	f.write(bytes(tmp))

example.zip

[MichaelTiemannOSC]

Watching to see how this progresses. Hope to see 2.0.0 break through soon!

[FHTMitchell]

@Gobot1234 What are the current blockers on this? Anything you need help with? Seems like this has been stuck in limbo for a nearly 2 years and I (and others it seems) are very keen for it!

[Gobot1234]

@Gobot1234 What are the current blockers on this? Anything you need help with? Seems like this has been stuck in limbo for a nearly 2 years and I (and others it seems) are very keen for it!

I think this still stands #256 (comment)

[terax6669]

@Gobot1234 What are the current blockers on this? Anything you need help with? Seems like this has been stuck in limbo for a nearly 2 years and I (and others it seems) are very keen for it!

Parser and/or exporter is broken, see my comment: #256 (comment)

[redbmk]

If the latest beta seems stable enough, would there be any opposition to publishing a v2 soon, and pushing any other breaking changes into v3?

@terax6669 would a fix for the issue you're seeing be considered a breaking change or would it just be a bugfix? e.g. it could ship in v2.0.1 or something?

[fazpu]

buf is blocking the use of v2.0.0b6 with an argument they are waiting for a stable release - bufbuild/plugins#95 (comment).

[lukasbindreiter]

Is there any update on a stable v2.0.0 release? Any issues in particular that are blocking right now, where contributors may be able to help out on?

[cetanu]

See this milestone here

https://github.com/danielgtaylor/python-betterproto/milestone/4

I would be particularly interested in assistance for the following issue

#212

I'm pretty low on time at the moment

[terax6669]

@lukasbindreiter

Could you create a code snippet that can show this behaviour (it doesn't need to include the details of the stuff you can't show) and submit a issue?

Still a problem with 2.0.0b5

with open('example_raw.proto', 'rb') as f:
	tmp = Example().parse(f.read())
with open('example_parsed.proto', 'wb') as f:
	f.write(bytes(tmp))

example.zip

IMO a big issue for certain use cases

[lukasbindreiter]

@cetanu Thanks for the pointers, maybe I'll take a look at the issue you mentioned when I find some time. Would be happy to help out and contribute here if possible.

@terax6669 I'm not quite sure I'm following your example.
I'm assuming a roundtrip of parsing and then serializing a Example message produces a different output then the original parsed bytes?
Afaik the wire format explicitly states:

Implications

• Do not assume the byte output of a serialized message is stable. This is especially true for messages with transitive bytes fields representing other serialized protocol buffer messages.
• see: https://protobuf.dev/programming-guides/encoding/#implications

Is this whats going on here or something else?

could you maybe share the Example message definition you are referencing above, otherwise it's kinda hard to reproduce / check in more detail.

[terax6669]

@lukasbindreiter
Order can change, but the data shouldn't.

That being said, I can no longer reproduce this issue - so looks like it was fixed in the meantime! 👍