-
-
Notifications
You must be signed in to change notification settings - Fork 255
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
support mintty (MSYS/Cygwin terminals) #226
base: master
Are you sure you want to change the base?
Conversation
Just a note that I came across this PR while trying to get colorama working with git's bash environment on Windows, and it worked like a charm! Would be great to see it merged. |
Hey. FYI, Yesterday I created a PR to test releases before we push them to PyPI. When that is merged, I'll be more confident about resuming merges and releases. I'll try to look at this PR soon. Thank you for creating it! |
Hello, what's the latest on this? Our team is suffering the same issue described above |
Hi @3tilley. I have been AWOL for years, but am now rounding up PRs that could get merged. I'll take a look at this. I'm currently biased against it because there are no tests, but I can see people want it. |
colorama/ansitowin32.py
Outdated
import msvcrt | ||
import ctypes | ||
import sys | ||
import re |
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.
Hey. Imports should be at the top of the file, not in functions. Thanks!
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.
moved to the top
colorama/ansitowin32.py
Outdated
@@ -13,6 +13,44 @@ | |||
winterm = WinTerm() | |||
|
|||
|
|||
def is_msys_cygwin_tty(stream): | |||
# https://github.com/msys2/MINGW-packages/pull/2675/files |
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.
Not a biggie, but I'd vote for putting this URL in the commit message (with a sentence explaining what it is, as you have done) not in the code. If people want more info about the function and where it came from, they can git blame it, and will find the URL.
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.
I've changed the commit message
inspired by https://github.com/msys2/MINGW-packages/pull/2675/files MSYS/Cygwin terminals (mintty) have filenames of the specific pattterns: (msys|cygwin)-<GUID>-pty<NUMBER>-(from|to)-master GetFileInformationByHandleEx is used to obtain a filename from the file descriptor https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfileinformationbyhandleex Signed-off-by: SSE4 <[email protected]>
Hi! Out of curiosity, is there any reason for implementing this using WinAPI and not simply checking for the |
to be honest, I am not sure how is it reliable. environment variable could be set to anything, e.g. after few quick tests, I can say spawning a cmd.exe from the MSYS2 terminal inherits I also don't know for which values to check. AFAIR ncurses has a (large) terminal database, so it might be not so simple to maintain a white-list of good/known TERM values. |
@SSE4 Thanks for answering! I agree checking for This is what is used by I was suggesting |
Is there anything outstanding with this PR? I know there was a test mention above, I don't know how the above could be tested sensibly though. How is it done for other terminals? |
@3tilley Hi there! Thank you for responding to my earlier comment from some time ago. Now that I look again, it reminds me of a 2nd comment I have about the 'import' statement. Sorry I didn't think of it earlier, and thank you for your patience. In reply to your question about testing: Yes, I agree having an end-to-end test for working with a particular terminal type, that is difficult to do, and such a test would have limited utility, since it would only be useful when executing the tests in that terminal type (we'd presumably have to skip the test if running elsewhere.) So other contributors which don't use that type of terminal would be unlikely to ever run your test, and CI would not be able to usefully run your test. It would be of very little use. (in many ways, that's why the various 'demo' scripts exist - so that people on a particular platform can eyeball the actual output as a sanity check) However, we can still write unit tests. The goal of these is that If someone comes along and modifies your code in the future, accidentally completely breaking it, would anything alert us to that? Or would we deploy the broken feature? If we add code without tests which would warn us of this problem, then IF someone breaks your code in the future, and we deploy that, annoying many users (we have a billion and a half downloads at this point) then the root cause of that failure would be the PR that introduced untested code, not the merge or deploy of the broken code. I'll write more in another comment, one sec... |
First, we'd need a unit test that isatty() calls your new function correctly. (ie. that it does call it, that it combines the result with something else using an 'or', and that it returns the result which uses this expression.) To do this, first write as simple a test as we can for which isatty returns False. Hopefully we could copy an existing test to obtain this. As a sanity check, run that test and watch it pass. Now modify the test, to assert that isatty returns True. To make that pass, modify the test so that in its setup, it does something that makes One non-trivial part of doing the above is that on non-windows platforms, the check for whether msvcrt imports will always return False, making the test fail no matter what we do. There are ways we could work around this, and right now I'm favoring the following: Instead of your test trying to make is_mysys_cygwin_tty actually return true, we won't bother, and will instead patch out that function, so that when isatty calls is_msys_cygwin_tty(), it is actually calling a function (or mock) that your test has provided, which always returns True. At this point, some people feel uncomfortable that the test isn't actually calling is_msys_cygwin_tty. So what's the point? The test isn't even running your new function. But remember, THIS test is supposed to be demonstrating that the change to isatty works. It doesn't, and shouldn't, care about whether is_mysys_cygwin_tty works. That's the job of a different test, which I'll describe in the next comment. |
The 2nd kind of unit tests needed are those that call is_mysys_cygwin_tty, and verifies it produces the correct outputs for various inputs. What we'd really like to do is start with a test that asserts is_mysys_cygwin_tty returns True. Then modify the test setup to do whatever we have to do to make that test pass. So, for example, the stream the test passes should have the correct attributes, etc. Again, there will be complications about doing windows-specific logic when the test is running on non-windows platforms (or indeed, on non-cygwin platforms.) There are a few possible workarounds.
In general, you'll need one test for each branch in the code-under-test. (If they interact, you might need to test the permutations of different branches, but I don't think that applies here.) When creating these tests, it's surprisingly common to create a test where you THINK the code under test is producing the expected output for one reason, but there's actually a bug in your test, and you've accidentally produced a test that will always pass, no matter what. To avoid bugs like this, use the following sequence:
I'll stop. I hope this is useful and not just infuriating. Hugs! |
It sounds like a philosophical debate about how useful mocks can be. I think you're probably right that it's appropriate here, but given that we have no control over the msvcrt symbols (or to be honest even know what they mean in my case), the mocking feels a little artificial. I would propose option 2 but with a pytest mark to not mock, so someone can trivially check it's doing the right thing by running in their terminal of choice. @SSE4 knock yourself out with the above, if you don't think you'll have time I can try and look sometime next week. |
unfortunately, it seems like I am not so good with mocks and don't know to properly mock modules like |
Mintty tests
thanks a lot, I have merged your tests, they look simple and good enough for me :) |
This is looking AMAZING. Thanks for all the hard work on getting this in such good shape. I belatedly enabled CI for this PR (I didn't realize that was an opt-in step. Thanks cryptocurrency 🙄), and it shows that I'll check in more detail this evening. THANK YOU! |
@3tilley there are some failed tests, can you take a look? |
@SSE4 can you permission me to push to that branch to just make it a bit quicker? |
sure, I have invited you as a collaborator to my fork. check your email. |
Update mock command
@tartley looks like you'll have to approve the CI run. I was hoping once you'd done it once I'd be safelisted |
@tartley apologies I overlooked a ModuleNotFoundError. I'd be interested in what your thoughts are about supported 3.5 and 2.7 now they're EoL, but the above should now be fixed. Do you mind approving another run at the CI? |
Awesome, looks like it passed this time! Is there anything else I can help with on this PR? |
Hello @tartley , is there anything we can do to help here? |
Hi, |
Hi. Thanks for the ping. The only "roadmap" that exists are the aspirational "0.4.6" (and similar) tags applied to some issues. The project is in maintenance mode, and doesn't receive enough attention to be adding new features, but aims to address bugs where possible. I'll take a look this weekend. |
Thanks for the quick reply, I am glad, it is not dead.
I don't know whether you consider this as a feature (add new term type) or
a bug (coloring on certain term doesn't work :-]]. Either way it seems to
me as a waste of effort already done on this issue to not finish it by
merging/releasing it. Judging from googling I am not the only one who would
like it :-).
On the other hand I must confess that I haven't worked on any project on
Github yet. So I have no idea how much I am requesting. If releasing it
(with others in similar state I suppose) would need half an hour's work or
two full days.
[image: width=]
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Neobsahuje
žádné viry.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
pá 16. 9. 2022 v 19:23 odesílatel Jonathan Hartley ***@***.***>
napsal:
… Hi. Thanks for the ping. The only "roadmap" that exists are the
aspirational "0.4.6" (and similar) tags applied to some issues. The project
is in maintenance mode, and doesn't receive enough attention to be adding
new features, but aims to address bugs where possible.
—
Reply to this email directly, view it on GitHub
<#226 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWR6GWRQLVLO2WWUMTTKM3V6SUJDANCNFSM4IJJ6XZQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
closes: #224
detect mintty (MSYS bash, Git bash, Cygwin bash, MinGW bash, etc)
based on https://github.com/msys2/MINGW-packages/pull/2675/files