Skip to content

Conversation

@spyoungtech
Copy link
Owner

spyoungtech commented May 11, 2024

Thanks for raising this. However, all code in the _sync directory is automatically generated. Changes to _sync/ must originate from _async/ changes.

(to avoid the code rewriting, you can also extract to the _utils module in the root of the package)

Sorry for you to run into this. I should probably get around to writing a contribution guide that explains all of this soon 😅

@trajano
Copy link
Author

trajano commented May 11, 2024

Thanks for raising this. However, all code in the _sync directory is automatically generated. Changes to _sync/ must originate from _async/ changes.

Oof that's probably why when I use the requirements.txt to point to my git repo my changes are not being reflected and I was wondering WTF... because this is the second one I am doing patch work for my weekend project jath03/openrgb-python#72 was the first and it seemed to work.

@coveralls
Copy link

Coverage Status

coverage: 77.477%. remained the same
when pulling cdb20ba on trajano:patch-1
into de90e94 on spyoungtech:main.

@trajano
Copy link
Author

trajano commented May 12, 2024

BTW if _sync is generated why is the source present in the repo?

@spyoungtech
Copy link
Owner

It perhaps doesn't have to be committed, and I've gone back and forth on whether it should be or not, but ultimately it made it easier for linting tools, mypy, sphinx/readthedocs, etc. to all work correctly and allows someone to see the source online like, say, if they're investigating a stacktrace that points to a line in the _sync code.

@trajano
Copy link
Author

trajano commented May 13, 2024

I yield. I am not familiar with Python enough to convert what I have to an async def when there's no await in the body.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants