- 主题:python package的构建现在越来越混乱了。
你rhel6那应该用不到什么新的东西啊
【 在 pcal 的大作中提到: 】
: 什么setup.py pyproject.toml, 什么easy_install, pip, 什么skbuild,什么cmake, meson, ninja,我就为了在一台rhel6上装pandas,我靠什么牛鬼蛇神全出来了,各种包打架。
: 起因是,我有个python库,用了比较新的cython,对pandas版本要求倒不高。现在要在老系统上跑,结果pandas老版本,就是用传统setup.py的那个,依赖老版本的cython,我自己的库用老cython编译过不了,只能升pandas到2.x,结果2.x的构建换成meson-python了,这破玩意一堆乱七八
: 愕囊览怠
: ...................
--
FROM 139.227.19.*
rhel不是“保证兼容”么,凭什么6里面只能到6.3呢?
【 在 pcal 的大作中提到: 】
: 没法用docker啊。
: 隔壁某公司还在用redhat as4构建软件。我这rhel6已经是上边界了,还得是6.3,高了还不行。
--
FROM 139.227.19.*
所以你选择了规避,而不是解决?
【 在 pcal 的大作中提到: 】
: 6.x内部小版本,在某些高版本的系统上build的,在低版本不一定能跑,有些库不一样。这是实践结果。
: 反正折腾了之后发现6.3是安全的。
--
FROM 139.227.19.*
这是库的问题啊
跟python有什么关系?
【 在 ToSimplicity 的大作中提到: 】
: 我是认为python的虚拟化隔离还是不足,
: 比如 libA和libB 是依赖
: 但libA要libX的1.0, libB要libX的2.0
: 就傻眼了
: 我认为隔离最好整个依赖树都隔离
: 装上多个requests就都装上
--
FROM 139.227.19.*
你可以带操作系统甚至带硬件发布
没必要按应用程序发布啊
【 在 pcal 的大作中提到: 】
: 不是规避,目标机版本参差不齐,而且无法让他们重做系统。比如某家是全6.4工作站,大约400个,64c,基本是全年满负荷运行。公司ceo都换了4茬了,系统都没有升级。
--
FROM 139.227.19.*
via network?
【 在 windchh 的大作中提到: 】
: 非要用新的pandas,搞个新机器装新OS,套层接口也可以搞
--
FROM 139.227.19.*