在维护 PyPI 包和项目的过程中，我常遇到两大痛点：
.whl 文件的项目还需要额外的环境配置，工作量会增加不少。近两年内，这些问题有了舒服的解决方案。
工作中，我们用了 uv 来管理 Python 项目，可以快速安装依赖和固定子依赖的版本信息。
我在一段时间的休假回来后例行更新电脑上的包库，发现 uv 有了新版本，于是我就更新了
uv。 结果在一个项目中更新 uv.lock 文件后发现有很多依赖的 wheels
从锁文件中消失了。 比如如下配置的 pyproject.toml 文件：
tzf 及相关项目的基础开发工作基本稳定了，在之前的文章零星有些开发和设计过程的资料:
这一篇是最终的总结，从项目的启动到逐步优化和演进的过程。
在彩云天气 App 和 API 里可以获取到当前经纬度的气象预警信息，比如「大风蓝色预警」。 不同国家地区的预警发布规则不一样，在中国是按照行政区划层级来发布的，其中最小到县级行政区。 所以在实现中，需要将经纬度转换成行政区划层级信息，再查找相关的预警信息。 在过去几年中，这部分模块经历了多次重构和完善，在此分享下每个版本的实现方式。
Protocol Buffers 生成的 Python 代码是一坨人类无法阅读的代码， 近日才发现 Google
增加了一个参数 --pyi_out=./xxx 就可以生成 Python 的 typing 了。
这个功能在官方文档里是一点没有提及。
tzfpy 是 tzf 的 Python
binding。 如果只是本地可用，Go 代码加上 CGO 扩展编译成 .so 文件就能用了。
不过要做成发布到 PyPI 上在其他地方能直接安装的 wheel 是有些曲折的，看 CI
失败的记录就挺明显的。
上回 说到在 Go 里弄出了一个
tzf
的库，可以非常快速得到经纬度所在的时区信息。
当时的想法是用 Rust 实现出来然后用 maturin 制作 Python 扩展。
经过一段时间的摸索发现 Rust 的坑有点大，于是 2022-07-23 转换了方向，在 Python
里调用 Go 编译出来的 .so 文件。 验证 demo 还算简单
ringsaturn/tzf#11。
距离决定用 FastAPI 重写 Flask 应用已经过去了一年了， 年中的时候在 FastAPI 上尝试了很多性能优化方案，但机器的负载水平已经快到头了， 只能承认这条路走不通，需要换一个快得多语言来做。 决定用 Go 再重写，又经历了若干次的优化，目前已经稳定运行。 线上峰值 QPS 接近 10K，应用内统计延迟在 2ms 之内，依赖服务统计延迟在 13ms 左右。 记录下若干有意思的事情。
在 2019 年夏天，我们将两个 Python 包
ujson 和
rb 做了些调整与更新，以适合 Python3.6+
环境下的运行。发现 PyPI
的发布比较繁琐，当时试图做些自动化的工作，但是没找到方向，就先搁置了。后来在一次的小版本发布时出现了
GitHub Release 的 tag 和 PyPI 最新版的 tag 不一致的情况
caiyunapp/ultrajson#8。