小编Deu*_*ina的帖子

更新:ipykeynel 4.4.18月9日早上修补了这个问题.

我有一个全新的安装,我一直在尝试让我的python依赖项启动并运行,即jupyter notebook和matplotlib.我已经安装了所有东西,并且"import matplotlib"有效.如果我在一个jupyter笔记本中,我尝试"import matplotlib.pyplot"或"从matplotlib import pyplot作为plt",我得到:

ImportError                               Traceback (most recent call last)
...
/usr/local/lib/python2.7/dist-packages/IPython/core/pylabtools.pyc in configure_inline_support(shell, backend)
    359     except ImportError:
    360         return
--> 361     from matplotlib import pyplot
    362
    363     cfg = InlineBackend.instance(parent=shell)

ImportError: cannot import name pyplot

完全追溯

但是,如果我在ipython(命令行)中,这可以正常工作.此外,从命令行的模块运行图表,很好.我尝试过各种技巧:

• 以各种顺序pip安装/卸载matplotlib,ipython和jupyter
• 使用pip和--no-cache-dir和/或--ignore-installed
• 删除〜/ .cache,〜/ .ipython和〜/ .jupyter
• 确保没有使用apt-get安装软件包,只安装了pip
• 使用apt-get安装python-matplotlib,ipython和python-jupyter

感觉我已经破坏了某种路径信息,但是我找不到会导致这种情况的原因或位置,特别是在多个pip卸载/重新安装和缓存清除之后.我已经阅读了有关导入matplotlib的每个SO问题,没有一个有用.

我回滚到matplotlib 1.4.3,这很有效,但它缺少我需要的一些功能.我意识到这可能是一个棘手的问题,所以如果你有任何见解,即使不完整,也会非常感激.此外,如果这是一个值得一个错误报告的东西(从来没有做过,不确定这是一个matplotlib问题,还是只是在本地搞砸了),请注释,我会提交一个.谢谢!

系统信息:

Linux Mint 18 "Sarah"
Python==2.7.12
ipykernel==4.4.0
ipython==5.0.0
ipython-genutils==0.1.0
ipywidgets==5.2.2
jupyter==1.0.0
jupyter-client==4.3.0
jupyter-console==5.0.0
jupyter-core==4.1.0
notebook==4.2.2
numpy==1.11.1
pip 8.1.2 from /usr/local/lib/python2.7/dist-packages (python 2.7)

在ipython和jupyter中输出sys.path(两者都相同):

['',
 '/usr/local/bin', …

这里完全是锈菜鸟。尝试为 linux x64 构建一个 sccache 二进制文件Redis: true。我从一个高山图像开始：

FROM rust:alpine3.10

WORKDIR /root

RUN apk --no-cache add --update curl
RUN curl -L https://github.com/mozilla/sccache/archive/0.2.11.tar.gz \
        -o sccache.tar.gz
RUN tar xf sccache.tar.gz

RUN cd sccache-0.2.11 &&\
    cargo build --features=all --release 

我得到：

error: cannot produce proc-macro for `derive-error v0.0.3` as the target `x86_64-unknown-linux-musl` does not support these crate types

如果FROM rust基于buster. 我可以只用这个（我会），但是这里发生了什么？我太不自在了，我什至不知道该问什么问题。

相关？：https : //github.com/rust-lang/rust/issues/59302

我有一个USB GPIO设备，其中包含一些第三方驱动程序，我想在容器中与其进行交互。编译，在主机上运行良好。也可以编译，如果我通过--device=/dev/bus/usb/001/$NUM其中 $NUM 是插入设备时自动生成的路径，则可以在容器中正常工作；我猜想 udev 正在分配这个。但是我想要一个确定性的绑定点，所以我修改了 udev规则来分配一个符号链接：

SUBSYSTEM=="usb", ATTR{idVendor}=="09db", 
ATTR{idProduct}=="0075", MODE="0666", 
TAG+="uaccess", TAG+="udev-acl", 
SYMLINK+="mcc_daq"

这给了我一个位于/dev/mcc_daqto的符号链接/dev/bus/usb/whatever。在主机上仍然可以正常工作。

但是，如果我运行：

docker run --rm -it \
        --device=/dev/mcc_daq \
        mcc_daq1

我明白了

usb_device_find_USB_MCC: libusb_open failed.: No such file or directory 
Failure, did not find a USB 2408 or 2408_2AO!

这是测试程序在找不到设备时输出的内容（使用libusb_get_device_descriptor）。

当我在容器中运行时，我得到的输出与使用 启动容器时的udevadm info -q all /dev/mcc_daq输出完全相同。但是，如果我将符号链接路径传递给docker，则无法查询绝对路径。 udevadm info -q all /dev/bus/usb/001/004--device=/.../004

udev 输出在主机系统上更加详细，我不确定这是否是问题或预期行为的一部分。我的直觉是缺少这些额外的条目意味着 libusb 可以找到设备，但找不到产品的供应商 ID。然而，udev 输出在容器中是相同的（无论是符号链接还是硬路径）这一事实让我对此产生疑问。

更新：新的有趣事实：当我在测试程序上运行 …

我有一些.protogRPC 文件要编译为 setup.py 脚本的一部分。这需要运行from grpc_tools import protoc和调用protoc 之前 setup(args)。目标是编译和安装 .pb 文件pip install pkgname。

例如

# setup.py

# generate our pb2 files in the temp directory structure
compile_protobufs(pkgname)

# this will package the generated files and put them in site-packages or .whl
setup(
    name=pkgname,
    install_requires=['grpcio-tools', ...],
    ...
)

这按预期工作，我在我的站点包或轮子中获取 pb 文件，而不必将它们存在于源文件夹中。但是，这种模式意味着我不能天真地pip install pkgname从头开始，因为步骤compile_protobufs取决于grpcio-tools，直到setup().

我可以使用 setup_requires，但那是在砧板上。我可以先安装依赖项（现在我使用RUN pip install -r build-require.txt && pip install …