morotti
morotti
alright, run on the largest envs I could find, 697 dependencies. `CacheInfo(hits=126981, misses=9902, maxsize=99999, currsize=9539)`
I've resent the PR. adjusted to 10000 max cache to fit large venvs. updated the news items. updated to main branch from today.
hello @pfmoore , this has no effect on memory usage. measuring memory usage on a few runs, the memory vary around 80-90MB. irrelevant of the cache size. the cache size...
https://github.com/astral-sh/uv/issues/4328 That one is an issue on windows. It's hard to tell what uv is doing because it's working from some cache with hardlinks or symlinks. pip extraction always erases...
Some newer benchmark, with the latest main pip branch. Running with the python interpreters from the manywheel official container image. Running on a VM, the location is some sort of...
wow, i was reviewing the code and I have to say I am surprised. let's not blame artifactory for badly written code. I am somewhat familiar with artifactory for managing...
> If basically one person can maintain backwards compatibility with almost little thought, why can't Artifactory manage the same Artifactory doesn't control user deployment. Even if they adjust their software...
Oh I was talking about another point. I totally agree that artifactory should not have changed the error message. It's an absolutely trivial bug that could have been trivially avoided...
The performance overhead of test coverage is insane - 5 times slower on python code - REPRO ATTACHED
hello, thanks for getting back to me. I was trying to do a bit of debugging. I've read some of your articles on writing coveragepy, nice blog by the way....
Hello, See linked issue https://github.com/moby/moby/pull/48106 In summary, gzip compression is slow, on the default level 6, it's compressing around 12 MB/s on my servers. There's a bug on moby (docker)...