给python安装numpy模块
当然不是“不可能”

我认为我们应该将新的依赖关系保持在最低限度。也就是说，网格切片器可能是 5% 的 bCNC 用户会使用的东西，并且会让 100% 的用户头疼。（即本期和#943、#942）

我的猜测是 90% 的用户没有使用 bCNC 的 CAM 功能。

有没有办法延迟插件的加载，以便只有在使用插件时才会触发这些错误？

@toktuff我知道，但 numpy 在很多情况下都非常有用，包括未来的新 CAM 功能。这是 python 世界中相当常见的数学主食。当我为 bCNC 开发新功能时，我一次又一次地遇到了 numpy。因此，SVG 导入也需要它，这在我看来很有用（激光人员和 CNC 新手倾向于使用 SVG 而不是 DXF，这使得 bCNC 对他们没有吸引力，因为将 SVG 转换为 DXF 是他们不需要的麻烦其他软件包）。我们可以将其设置为可选，但随后我们会让用户感到困惑，他们会问为什么某些功能无法正常工作…强制用户从一开始就正确安装比不得不解释为什么某些功能在他们的系统上损坏要好。

这是一个相当艰难的决定。但这种“不是在这里发明”的方法并不总是最好的。例如，bpath.py 库（它是 bCNC 的 CAM 的基础）在很多方面都被破坏了。即使是基本功能也有问题。有时它无法正确判断该点是否在形状内部。制作路径偏移量（配置文件）的代码有一些错误，交集代码有时会表现得很奇怪，等等……如果我们能够使用一些由更大的社区维护和测试的外部几何库，那肯定会更容易。这也将使 3D CAM 的实施变得更加容易，从而发挥 bCNC 的潜力。CNCCanvas.py 也是如此，它不能抗锯齿，而且速度太慢，无法通过鼠标实时旋转视图。但是可以用OpenGL代替。

现在 python 有了 PIP，应该很容易自动安装一些依赖项以使用户舒适。它还将缓解 bCNC 目前存在的许可问题，因为我们将能够使用不兼容 GPLv2 的库。我认为我们应该弄清楚 bCNC 可以利用的几个新部门，而 numpy 和 opengl 肯定是有趣的。

当然，我并不是说 bCNC 应该疯狂地引入新的依赖项，但它应该是理智的，除非我们希望 bCNC 随着时间的推移变老、脾气暴躁和退休。

我的猜测是 90% 的用户没有使用 bCNC 的 CAM 功能。

我们可以使 bCNC 中的 CAM 功能非常酷，以至于他们会开始使用它们:-) 如果他们已经将 bCNC 用作 g 代码发送器，我想如果 bCNC 包含所有功能，他们就不会使用外部 CAM。在单一窗口中做所有事情更容易。问题是 bCNC 的 CAM 必须获得新功能才能更具吸引力。

对我来说，方法是：首先让功能发挥作用。然后我们可以努力减轻依赖性。我添加了依赖于 scipy 和 enump 库的网格切片器，然后我设法通过重写代码来删除这两个依赖项。但我认为让东西正常工作应该是优先事项。对我来说，仅仅为了不必安装库而牺牲功能是没有意义的。那不是你制作有用软件的方式。