python-odin/odin

What's blocking feature/poetry from being merged into development?

Closed this issue · 4 comments

gc-ss commented

@timsavage I really appreciate this project.

My usecase would be to use the dataclasses fork of this code (w/o the metaclasses).

I would like to hit a specific SHA in this repo from my poetry project - so having this be packaged by poetry would really help.

2 questions:

  1. What's blocking feature/poetry from being merged into development? I would like to help if I understand the block(ers)

  2. Can't this be resolved by setting the correct path structure as expected by pytest? https://github.com/python-odin/odin/compare/feature/poetry#diff-e52e4ddd58b7ef887ab03c04116e676f6280b824ab7469d5d3080e5cba4f2128R6

timsavage commented

My main hold up is time to get the work done, there are a few motivations for switching to poetry mainly for my productivity. I'd have to look into where I was at with poetry update, I have a raft of small fixes (mainly around typing) that need to be applied.

I've done a lot of thinking about how to utilise the dataclasses fork of the code, these would likely be optional for the time being as backwards compatibility with the existing code is required. I know this library is still heavily used in environments that are stuck on Python 2.7.

I'll try to put a bit of a roadmap together for when some of these features can land and when I can draw a line in the sand regarding dropping Python 2.7.

  • 👍1
gc-ss commented

My main hold up is time to get the work done

Understood. That's what I assumed and you confirmed it. I would like to help if you can tell me some of the things you would like to see done

there are a few motivations for switching to poetry mainly for my productivity

I assure you, this migration to poetry will help all the users boost their productivity too!

I'd have to look into where I was at with poetry update, I have a raft of small fixes (mainly around typing) that need to be applied.

Can you give me some more context? I did see some formatting and other commmits in this branch that looked orthogonal to the poetry migration but I am unfamiliar with this codebase.

What I'm getting at is - it's best if we completely isolate the minimum commmits needed for the poetry migration to this branch and keep any other commmits on a separate branch.

That could help manage the complexity better and allow us to merge this branch in quicker?

I've done a lot of thinking about how to utilise the dataclasses fork of the code, these would likely be optional for the time being as backwards compatibility with the existing code is required. I know this library is still heavily used in environments that are stuck on Python 2.7.

Understood. I was thinking that we fork the Python 2.7 bits into a Python 2.7 branch and treat the master/dev branch as Python 3

Eventually the Python 2.7 branch dies a natural death while the Python 3 branches live on.

I'll try to put a bit of a roadmap together for when some of these features can land and when I can draw a line in the sand regarding dropping Python 2.7.

Appreciate the good work Tim. Thank you for all of this

timsavage commented

I have done a bit of a cleanup, the poetry migration is now completed.

Also:

  • Disabling/removing old code analysis tools and replacing them all with Sonar
  • Moving from Travis CI to Github Actions
  • Fixing some of the typing issues
timsavage commented

For Python 2.7 support it will get the tying fixes and a couple of hygiene fixes from Sonar along with the Toml codec.

Plan moving forward is pin the last release supporting Python 2.7 at an upcoming 1.6 any important bugfixes will go on a support branch.

Python 3.6+ features will then be added for version 2.0.

  • 🎉1
  • ❤️1