E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct
517 karma · joined August 5, 2018
E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct
I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)
There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)
> It turns out that only 9 of the first 275 checks that I've sent out since the beginning of 2006 have actually been cashed. The others have apparently been cached. So this change in policy will probably not affect too many people. On the other hand, I don't like to renege on promises, so I shall do my best to find a suitable way to send money to anyone who really prefers legal tender.
I personally sort by ‘date modified (newest first)’ on StackExchange sites.
Use `env:` instead and just work with environment variables in your shell script.
Yes, you still need to vet your script. Quoting is a common source of problems. Use shellcheck. Do not call eval/source/python/perl/whatever with untrusted input.
But you removed one layer of problems already by not pasting a value into your shell script code directly.
Use this instead of x87’s FDIV
But they have regular installers, they are called .pkg and look like a wizard. Programs distributed as a single .app don’t really need them though.
The old Unicode rules for ZWNBSP are also quite tricky: you are not supposed to ignore the first ZWNBSP if you already know the encoding. Which means to express an initial actual ZWNBSP you need to write two of them if the encoding is unknown to the receiver and only one of them if known.
> Where the character set information is explicitly marked, such as in UTF-16BE or UTF-16LE, then all U+FEFF characters, even at the very beginning of the text, are to be interpreted as zero width no-break spaces. Similarly, where Unicode text has known byte order, initial U+FEFF characters are also not required and are to be interpreted as zero width no-break spaces. For example, for strings in an API, the memory architecture of the processor provides the explicit byte order. For databases and similar structures, it is much more efficient and robust to use a uniform byte order for the same field (if not the entire database), thereby avoiding use of the byte order mark. Systems that use the byte order mark must recognize that an initial U+FEFF signals the byte order; it is not part of the textual content. It should be removed before processing, because otherwise it may be mistaken for a legitimate zero width no-break space. To represent an initial U+FEFF ZERO WIDTH NO-BREAK SPACE in a UTF-16 file, use U+FEFF twice in a row. The first one is a byte order mark; the second one is the initial zero width no-break space.
— Unicode 3.0 Standard, p. 325 <https://www.unicode.org/versions/Unicode3.0.0/ch13.pdf>
(With modern Unicode you can write WJ or ZWNBSP,WJ and there is no problem)
Correct. That’s using the wrong base. Decimal floating point doesn’t have that problem.
It also does not collapse lines when there’s a trailing comma.
Your output seems to be from black. IMO it’s insane to collapse lines when there are line comments.
$ uvx ruff format --diff formatting.py
--- formatting.py
+++ formatting.py
@@ -1,8 +1,4 @@
-no_comma = {
- "x": 3,
- "y": 42,
- "z": 2
-}
+no_comma = {"x": 3, "y": 42, "z": 2}
with_comma = {
"x": 3,
@@ -12,6 +8,6 @@
comment = {
"x": 3,
- "y": 42, # Answer to the Ultimate Question!
- "z": 2
+ "y": 42, # Answer to the Ultimate Question!
+ "z": 2,
}
1 file would be reformatted
(I intentionally switched to double quotes since that really is a stylistic choice in Python, you can escape in both, and if you use double quotes inside of single quotes ruff leaves it as-is) [chrome-demo] chrome assets ready
[gecko] warning: unsupported syscall: __syscall_madvise
[gecko] embed-xul: main() on the app pthread (PROXY_TO_PTHREAD)
[gecko] embed-xul: GECKO_GL_PASSTHROUGH=1
[gecko] embed-xul: GECKO_COARSE_CLOCK=1
[gecko] embed-xul: GECKO_GPU=1 (GPU/WebRender->canvas rendering)
[gecko] xul_init: GRE dir = /gre
[gecko] Pthread 0x11051000 sent an error! blob:https://developer.puter.com/edc1bd0a-b844-4a18-a69a-63dd49dc304a:8906: SecurityError: Security error when calling GetDirectoryA lot of non-language tools bring their own certificate bundle as well, like uv, git, curl and Firefox. (I think they might all be the same Mozilla bundle even).
However, it seems like the situation here has improved slightly: git can read Windows certificates now once a flag has been set, Firefox has a flag for Windows and macOS, and it supports p11-kit. curl can be built with Windows/macOS support and respects OpenSSL environment variables. uv can be configured to use system-certs.
And obviously any VM or container has to be set up separately. That often includes stuff like pipelines in forges. As mentioned in the sibling comment, at least here it's definitely by design.
NL Next line (from EBCDIC?)
LS Line separator (invented by Unicode)
PS Paragraph separator (same)
The Unicode standard says that in addition to CR, LF, CRLF and the above, vertical tabs and form feeds should also be treated as line separators.