-
-
Couldn't load subscription status.
- Fork 27
Minor improvements to setup.py #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Current coverage is 100% (diff: 100%)
@@ master #4 diff @@
===================================
Files 5 5
Lines 512 512
Methods 0 0
Messages 0 0
Branches 0 0
===================================
Hits 512 512
Misses 0 0
Partials 0 0 Powered by Codecov. Last update d190466...5c12c09
no longer in beta?
Heh, good catch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Figures out the path to setup.py, even if it's not in the current directory, and then changes the file name of the path to README.rst and finally reads the file contents as UTF-8 (the explicit encoding is necessary on Anaconda installs [like on RTD] where str.decode() for some incomprehensible reason does not default to utf-8!).
In the early days of my most popular project, APScheduler, I got a PR from someone who was doing RPM packaging of APScheduler. They were complaining that apscheduler's setup.py assumes that the working directory is the project directory, which apparently is not always the case. This line avoids that by not assuming anything about the CWD (and it closes the properly too, not that it really matters in the case of setup.py).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assumes that the working directory is the project directory, which apparently is not always the case.
......wuuut. really? .....I'm suddenly paranoid about all my packages. really? yikes.
Anything else you need, or should I roll a 1.3 release to get the yield_ change out for you?
I took a stab at adding type hints but I wasn't sure what types to put where, so I gave up for now. I've already released v1.3 of asyncio_extras which now depends on async_generator.
'kay, v1.4 is up on pypi (not sure why I said 1.3 above)
I assume that as of at least v1.3, this is no longer in beta?