Something weird is happening with psutil on Travis.

  running build_ext
  building 'psutil._psutil_linux' extension
  creating build/temp.linux-x86_64-3.6
  creating build/temp.linux-x86_64-3.6/psutil
  x86_64-conda_cos6-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O2 -Wall -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -fdebug-prefix-map=/home/conda/feedstock_root/build_artifacts/python_1551150806669/work=/usr/local/src/conda/python-3.6.7 -fdebug-prefix-map=/home/travis/miniconda/envs/manubot=/usr/local/src/conda-prefix -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -fdebug-prefix-map=/home/conda/feedstock_root/build_artifacts/python_1551150806669/work=/usr/local/src/conda/python-3.6.7 -fdebug-prefix-map=/home/travis/miniconda/envs/manubot=/usr/local/src/conda-prefix -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_VERSION=551 -DPSUTIL_LINUX=1 -I/home/travis/miniconda/envs/manubot/include/python3.6m -c psutil/_psutil_common.c -o build/temp.linux-x86_64-3.6/psutil/_psutil_common.o
  unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
  error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1

Possible we may need conda install gxx_linux-64to compile psutil.
RcppCore/Rcpp#770

Also possible that conda update conda is doing something with libgcc that is breaking something:
travis-ci/travis-ci#8512

@dhimmel Have you seen this Travis error before?

Have you seen this Travis error before?

No.

Also possible that conda update conda is doing something with libgcc that is breaking something:

We don't run conda update conda in:

I'll have more time to look tomorrow, but I've restarted the build in case it's temporary. Otherwise, perhaps we can add a workaround, as suggested in the other issues, to this PR.

Thanks. Also failing on a clone of this repository I made last night for a new manuscript, so it's not unique.

Thanks. Also failing on a clone of this repository I made last night for a new manuscript, so it's not unique.

This is bad. Perhaps we want to enable daily cron builds of rootstock so we can more quickly discover and pinpoint these issues. This is disappointing because we have tried to pin as much as possible regarding our conda environment. However, the environment is still changing (and breaking). A good reason for us to switch to docker where CI runs don't have to rebuild the env each time.

Possible we may need conda install gxx_linux-64to compile psutil.

Turned out installing conda's precompiled psutil (rather than pip) fixed the issue.

It would be nice if there was a way to use conda to help us locate which versions of the unpinned packaged had changed between builds. In this case, psutil was updated from 5.5.0 (last successful build) to 5.5.1 (failed build) on PyPI on February 15. We don't want to create that infrastructure though.

Docker may indeed be the best solution here. I expect we would still want to maintain a functional conda environment but could use Docker for reliable builds.

I'm now realizing that it may not be as simple as the version of a single package. Other manubot builds are still passing even with psutil 5.5.1.

Docker may indeed be the best solution here. I expect we would still want to maintain a functional conda environment but could use Docker for reliable builds.

I've used Docker a few times in the past, but not within the past year or so. Is there a simple recommended way for package maintainers to effectively say to users: "Here is our Docker image, to use it execute this one line"? Or is it still a multistep process with potential permissions issues (still need sudo access on linux/macOS)? Have either of you used Singularity? I think our large clusters here have largely migrated from Docker to Singularity.

Is there a simple recommended way for package maintainers to effectively say to users: "Here is our Docker image, to use it execute this one line"?

@slochower I am no Docker expert, but in my limited experience I'd say that yes it easy to do that if you already have Docker configured on your system.

Have either of you used Singularity?

I haven't used Singularity much. I too have seen a lot of clusters migrating to Singularity. My understanding is that Singularity can run Docker containers so there is no major downside to creating a Docker container for Singularity or Docker users.