- 主题:python package的构建现在越来越混乱了。
你非要用这种古董的发行版跑最新版本的软件。
我自己强行限制自己写的代码兼容 c++ 11,结果发现在 g++ 4.8 上面有个 c++11 的特性不支持。兼容老软件太难了,一般的程序员真的没时间去测试。
【 在 pcal 的大作中提到: 】
: 没法用docker啊。
: 隔壁某公司还在用redhat as4构建软件。我这rhel6已经是上边界了,还得是6.3,高了还不行。
--
FROM 59.60.24.*
libc版本跟不上
【 在 lvsoft 的大作中提到: 】
: 别自己build啊,dist是干嘛的。
: 一定要自己build那就别抱怨,比这个更折腾的东西多的去了。
:
--
FROM 58.210.115.*
ai 重灾区是因为Python要依赖C,Cpp,cuda,然后这些又依赖 系统,处理器架构,python 不背这个锅
【 在 lvsoft 的大作中提到: 】
:
: ai基本上是混乱的重灾区,所有的版本号都强关联,能一路一直给你锁到驱动版本。
: 基本上就是我这样调通了就行了,哪管别人洪水滔天。
:
: 所以我是坚决不用docker。我就是所有库都用发行版的发布并保持到它能更新的最新版本。然后所有的ai任务都得往这个版本port,能port过来就用port不过来我就不用。要不然这日子没法过了
#发自zSMTH@PCT-AL10
--
FROM 118.81.13.*
兼容老软件就是浪费生命。
【 在 hgoldfish 的大作中提到: 】
: 你非要用这种古董的发行版跑最新版本的软件。
: 我自己强行限制自己写的代码兼容 c++ 11,结果发现在 g++ 4.8 上面有个 c++11 的特性不支持。兼容老软件太难了,一般的程序员真的没时间去测试。
--
FROM 125.33.39.*
有一个生成ebook的也需要老的库
感觉很麻烦啊。这种开源的就容易这种情况
不跟上整体的脚步就完蛋了
这方面windows一以贯之的exe真的是猛
【 在 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 108.29.173.*
docker是一个微型的虚拟机么
可以建构一个环境?
docker在win和mac下哪个运行更好
【 在 flw 的大作中提到: 】
: 所以 Docker 是个好东西啊。
: 只可惜 rhel6 没法用,
: 我现在这一类需求都用 Docker。
: ...................
--
FROM 108.29.173.*
我好像完全没有说Python吧?事实上ai一锅炖就是比Python package复杂的多也乱的多的典型案例啊
【 在 VincentGe 的大作中提到: 】
: ai 重灾区是因为Python要依赖C,Cpp,cuda,然后这些又依赖 系统,处理器架构,python 不背这个锅
:
: #发自zSMTH@PCT-AL10
--
FROM 117.136.46.*
那升级libc啊
libc升不了换系统啊
系统不让换那换公司啊
要么做正确的事,用脚投票别惯着。
要么自己的选择自己承受,打碎牙自己吞忍着。
天底下无非就这么2个选项而已。
【 在 pcal 的大作中提到: 】
: libc版本跟不上
--
FROM 117.136.46.*
所以你选择了规避,而不是解决?
【 在 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.*