New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recent conda changes breaking Travis #6030

Closed
bashtage opened this Issue Sep 27, 2017 · 77 comments

Comments

Projects
None yet
@bashtage

bashtage commented Sep 27, 2017

Not 100% sure that this is a conda issue, but it looks like changes in .27 are breaking Travis builds that
use extension modules.

In particular, the compiler is identified as

compiler: x86_64-conda_cos6-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O2 -Wall -Wstrict-prototypes -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -fPIC

Not sure why conda would be in the compiler.

And example of a failed build can be see https://travis-ci.org/statsmodels/statsmodels/builds/280537305

@msarahan

This comment has been minimized.

Show comment
Hide comment
@msarahan

msarahan Sep 27, 2017

Contributor

This is because python bakes in compiler flags at build time. We have used new compilers in the 4.3.27 miniconda. These are available as gcc_linux-64, but it's better to use conda-build 3 and the new compiler jinja2 function.

Here's a recipe for statsmodels that has been modified to use conda-build 3 features: https://github.com/anacondarecipes/statsmodels-feedstock

Contributor

msarahan commented Sep 27, 2017

This is because python bakes in compiler flags at build time. We have used new compilers in the 4.3.27 miniconda. These are available as gcc_linux-64, but it's better to use conda-build 3 and the new compiler jinja2 function.

Here's a recipe for statsmodels that has been modified to use conda-build 3 features: https://github.com/anacondarecipes/statsmodels-feedstock

@bashtage

This comment has been minimized.

Show comment
Hide comment
@bashtage

bashtage Sep 27, 2017

Is the solution to install gcc_linux-64 so that the normal python setup.py develop will correctly build?

bashtage commented Sep 27, 2017

Is the solution to install gcc_linux-64 so that the normal python setup.py develop will correctly build?

@msarahan

This comment has been minimized.

Show comment
Hide comment
@msarahan

msarahan Sep 27, 2017

Contributor

gcc_linux-64 will provide x86_64-conda_cos6-linux-gnu-gcc - this is a "prefixed" compiler - the stuff preceding gcc is known as the triplet, in gcc terms. Installing the package might work, but it also might not, depending on whether you activate the build environment. If you do, it should work, if you don't, it probably won't be on PATH, and won't work.

It's a bug in our python packages that things are not falling back to your system gcc. We're going to change the symlinks for miniconda-latest to point to the older release until we have this fixed. Sorry for the headache.

Contributor

msarahan commented Sep 27, 2017

gcc_linux-64 will provide x86_64-conda_cos6-linux-gnu-gcc - this is a "prefixed" compiler - the stuff preceding gcc is known as the triplet, in gcc terms. Installing the package might work, but it also might not, depending on whether you activate the build environment. If you do, it should work, if you don't, it probably won't be on PATH, and won't work.

It's a bug in our python packages that things are not falling back to your system gcc. We're going to change the symlinks for miniconda-latest to point to the older release until we have this fixed. Sorry for the headache.

@bashtage

This comment has been minimized.

Show comment
Hide comment
@bashtage

bashtage Sep 27, 2017

Thanks.

I did a conda install gcc_linux-64 and conda .27 recommended upgrading a Python 3.5 to a Python 3.6 install, which seems pretty heavy handed.

bashtage commented Sep 27, 2017

Thanks.

I did a conda install gcc_linux-64 and conda .27 recommended upgrading a Python 3.5 to a Python 3.6 install, which seems pretty heavy handed.

@kalefranz

This comment has been minimized.

Show comment
Hide comment
@kalefranz

kalefranz Sep 27, 2017

Member

I did a conda install gcc_linux-64 and conda .27 recommended upgrading a Python 3.5 to a Python 3.6 install, which seems pretty heavy handed.

This is probably a result of #5923

Member

kalefranz commented Sep 27, 2017

I did a conda install gcc_linux-64 and conda .27 recommended upgrading a Python 3.5 to a Python 3.6 install, which seems pretty heavy handed.

This is probably a result of #5923

@lesteve

This comment has been minimized.

Show comment
Hide comment
@lesteve

lesteve Sep 27, 2017

Similar problem for scikit-learn for example https://travis-ci.org/scikit-learn/scikit-learn/jobs/280535821. Not sure why but it seems to be happening only for our Python 2.7 build using conda. I am hoping to work-around the problem by using an older miniconda installer and not do conda update conda.

lesteve commented Sep 27, 2017

Similar problem for scikit-learn for example https://travis-ci.org/scikit-learn/scikit-learn/jobs/280535821. Not sure why but it seems to be happening only for our Python 2.7 build using conda. I am hoping to work-around the problem by using an older miniconda installer and not do conda update conda.

@kalefranz

This comment has been minimized.

Show comment
Hide comment
@kalefranz

kalefranz Sep 27, 2017

Member
Member

kalefranz commented Sep 27, 2017

@msarahan

This comment has been minimized.

Show comment
Hide comment
@msarahan

msarahan Sep 27, 2017

Contributor

As Kale said, we changed the "latest" minicondas to point at the 4.3.21 version from June. We have a fix, and are building packages. We'll upload new minicondas after testing. Sorry for the trouble.

Updating conda triggers this because updating conda pulls in packages from the new "main" channel, which is part of defaults. That channel has the new python builds that are causing this issue. Updating our python packages will be the fix.

Contributor

msarahan commented Sep 27, 2017

As Kale said, we changed the "latest" minicondas to point at the 4.3.21 version from June. We have a fix, and are building packages. We'll upload new minicondas after testing. Sorry for the trouble.

Updating conda triggers this because updating conda pulls in packages from the new "main" channel, which is part of defaults. That channel has the new python builds that are causing this issue. Updating our python packages will be the fix.

@lesteve

This comment has been minimized.

Show comment
Hide comment
@lesteve

lesteve Sep 27, 2017

Great stuff, thanks!

lesteve commented Sep 27, 2017

Great stuff, thanks!

@hainm

This comment has been minimized.

Show comment
Hide comment
@hainm

hainm Sep 28, 2017

gcc: error: unrecognized command line option ‘-fstack-protector-strong’
gcc: error: unrecognized command line option ‘-fno-plt’

I got this today :(

hainm commented Sep 28, 2017

gcc: error: unrecognized command line option ‘-fstack-protector-strong’
gcc: error: unrecognized command line option ‘-fno-plt’

I got this today :(

lesteve added a commit to lesteve/scikit-learn that referenced this issue Sep 28, 2017

mstimberg added a commit to brian-team/brian2 that referenced this issue Sep 28, 2017

@twiecki

This comment has been minimized.

Show comment
Hide comment
@twiecki

twiecki Sep 28, 2017

Contributor

I'm getting when travis is trying to build subprocess32.

  x86_64-conda_cos6-linux-gnu-gcc -pthread -fno-strict-aliasing -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -DNDEBUG -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/travis/miniconda2/envs/testenv/include/python2.7 -c _posixsubprocess.c -o build/temp.linux-x86_64-2.7/_posixsubprocess.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
Contributor

twiecki commented Sep 28, 2017

I'm getting when travis is trying to build subprocess32.

  x86_64-conda_cos6-linux-gnu-gcc -pthread -fno-strict-aliasing -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -DNDEBUG -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/travis/miniconda2/envs/testenv/include/python2.7 -c _posixsubprocess.c -o build/temp.linux-x86_64-2.7/_posixsubprocess.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
@sandys

This comment has been minimized.

Show comment
Hide comment
@sandys

sandys Sep 28, 2017

hi guys,
is there a workaround for this ? all our builds are failing . I installed gcc_linux-64, but i keep getting other errors (cc1plus not found, etc)

sandys commented Sep 28, 2017

hi guys,
is there a workaround for this ? all our builds are failing . I installed gcc_linux-64, but i keep getting other errors (cc1plus not found, etc)

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Sep 28, 2017

Contributor
Contributor

mingwandroid commented Sep 28, 2017

@lesteve

This comment has been minimized.

Show comment
Hide comment
@lesteve

lesteve Sep 28, 2017

The simple work-around I am using for scikit-learn (and for myself) is: do NOT do conda update in your root conda environment. Otherwise this picks up a conda that has the problem (4.3.27-py36h2866c0b_0 for me on Python 3.6).

Doing this you stay with conda 4.3.25 and you are not affected by this issue.

lesteve commented Sep 28, 2017

The simple work-around I am using for scikit-learn (and for myself) is: do NOT do conda update in your root conda environment. Otherwise this picks up a conda that has the problem (4.3.27-py36h2866c0b_0 for me on Python 3.6).

Doing this you stay with conda 4.3.25 and you are not affected by this issue.

@twiecki

This comment has been minimized.

Show comment
Hide comment
@twiecki
Contributor

twiecki commented Sep 28, 2017

@sandys

This comment has been minimized.

Show comment
Hide comment
@sandys

sandys Sep 28, 2017

i may have a partial fix.
i changed my meta.yaml to the following and it kinda worked. it is still failing on test.


build:
    number: {{ build }}
    script: python setup.py install --single-version-externally-managed --record record.txt

requirements:
  host:
    - python
    - setuptools
    - cython 0.26*
    - numpy 1.12*
  build:
    - python
    - opencv 3.1*
    - numpy 1.12*
    - {{ compiler('cxx') }}
    - cython 0.26*
  run:
    - python
    - opencv 3.1*
    - numpy 1.12*
    - cython 0.26*

sandys commented Sep 28, 2017

i may have a partial fix.
i changed my meta.yaml to the following and it kinda worked. it is still failing on test.


build:
    number: {{ build }}
    script: python setup.py install --single-version-externally-managed --record record.txt

requirements:
  host:
    - python
    - setuptools
    - cython 0.26*
    - numpy 1.12*
  build:
    - python
    - opencv 3.1*
    - numpy 1.12*
    - {{ compiler('cxx') }}
    - cython 0.26*
  run:
    - python
    - opencv 3.1*
    - numpy 1.12*
    - cython 0.26*
@bashtage

This comment has been minimized.

Show comment
Hide comment
@bashtage

bashtage Sep 28, 2017

@lesteve 's fix is working in statsmodels.

bashtage commented Sep 28, 2017

@lesteve 's fix is working in statsmodels.

@bashtage

This comment has been minimized.

Show comment
Hide comment
@bashtage

bashtage Sep 28, 2017

@twiecki You need to pin conda<=4.3.25

From your build log during an installation:

 conda-4.3.27               |   py27hff99c7a_0         508 KB

bashtage commented Sep 28, 2017

@twiecki You need to pin conda<=4.3.25

From your build log during an installation:

 conda-4.3.27               |   py27hff99c7a_0         508 KB
@sandys

This comment has been minimized.

Show comment
Hide comment
@sandys

sandys Sep 28, 2017

sandys commented Sep 28, 2017

@twiecki

This comment has been minimized.

Show comment
Hide comment
@twiecki

twiecki Sep 28, 2017

Contributor

@bashtage I thought it was replaced by @mingwandroid:

The lastest minicondas have been temporarily replaced with the previous one while we name a fix here.

Contributor

twiecki commented Sep 28, 2017

@bashtage I thought it was replaced by @mingwandroid:

The lastest minicondas have been temporarily replaced with the previous one while we name a fix here.

@bashtage

This comment has been minimized.

Show comment
Hide comment
@bashtage

bashtage Sep 28, 2017

AFAIU The miniconda install was changed so that the default conda is < 4.3.27, the problematic one. Your environment creation is triggering an automatic update of conda to latest, which is 4.3.27. The conda hasn't been unpublished -- only the miniconda(2/3)-latest installer has been retargetted.

bashtage commented Sep 28, 2017

AFAIU The miniconda install was changed so that the default conda is < 4.3.27, the problematic one. Your environment creation is triggering an automatic update of conda to latest, which is 4.3.27. The conda hasn't been unpublished -- only the miniconda(2/3)-latest installer has been retargetted.

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 8, 2017

Contributor

Something seems to be going on with github today. I also posted multiply.

Contributor

mingwandroid commented Nov 8, 2017

Something seems to be going on with github today. I also posted multiply.

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

Maybe this should be a separate issue, but I'm getting x86_64-conda_cos6-linux-gnu-gcc: command not found and x86_64-conda_cos6-linux-gnu-c++: command not found when trying to install R packages in R with install.packages(). Installation of R packages works via conda (eg., conda install -r r-ggplot2, but not via install.packages().

Using conda is fine for R packages available via conda, but what about the packages that aren't available or are broken? For example, conda install -c bioconda bioconductor-phyloseq generates the following error when loading the phyloseq package:

> library(phyloseq)
Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/ebio/abt3_projects/software/dev/miniconda3/envs/phyloseq/lib/R/library/stringi/libs/stringi.so':
  libicui18n.so.58: cannot open shared object file: No such file or directory

I tried conda install gcc_linux-64 as suggested by @mingwandroid on StackOverflow, but I still get x86_64-conda_cos6-linux-gnu-c++: command not found. The only file in ./miniconda/bin/ that resembles this file is x86_64-conda_cos6-linux-gnu-c++filt. Should the "filt" be appended to the name of this file?

I'm using r-base v3.4.1 from the r channel, conda v4.3.30, Ubuntu 16.04.3

nick-youngblut commented Nov 11, 2017

Maybe this should be a separate issue, but I'm getting x86_64-conda_cos6-linux-gnu-gcc: command not found and x86_64-conda_cos6-linux-gnu-c++: command not found when trying to install R packages in R with install.packages(). Installation of R packages works via conda (eg., conda install -r r-ggplot2, but not via install.packages().

Using conda is fine for R packages available via conda, but what about the packages that aren't available or are broken? For example, conda install -c bioconda bioconductor-phyloseq generates the following error when loading the phyloseq package:

> library(phyloseq)
Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/ebio/abt3_projects/software/dev/miniconda3/envs/phyloseq/lib/R/library/stringi/libs/stringi.so':
  libicui18n.so.58: cannot open shared object file: No such file or directory

I tried conda install gcc_linux-64 as suggested by @mingwandroid on StackOverflow, but I still get x86_64-conda_cos6-linux-gnu-c++: command not found. The only file in ./miniconda/bin/ that resembles this file is x86_64-conda_cos6-linux-gnu-c++filt. Should the "filt" be appended to the name of this file?

I'm using r-base v3.4.1 from the r channel, conda v4.3.30, Ubuntu 16.04.3

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 11, 2017

Contributor

No this is not related. To use install.packages() on any R on Linux you need compilers. To use install.packages() on Anaconda Distribution R on Linux you need Anaconda Distribution compilers. Here you are trying to compile a package that needs C++ compilers, so you need to install gxx_linux-64.

Contributor

mingwandroid commented Nov 11, 2017

No this is not related. To use install.packages() on any R on Linux you need compilers. To use install.packages() on Anaconda Distribution R on Linux you need Anaconda Distribution compilers. Here you are trying to compile a package that needs C++ compilers, so you need to install gxx_linux-64.

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

Sorry for asking in the wrong spot. Thanks for the clarification. For what it's worth, running the following fixed the issue:

conda install gcc_linux-64
conda install gxx_linux-64

I still get an error when installing the mnormt package:

/ebio/abt3_projects/software/dev/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gfortran   -fpic  -fopenmp -march=
nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/ebio/abt3_projects
/software/dev/miniconda3/include -L/ebio/abt3_projects/software/dev/miniconda3/lib  -c biv-nt.f -o biv-nt.o
make: /ebio/abt3_projects/software/dev/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gfortran: Command not found
/ebio/abt3_projects/software/dev/miniconda3/lib/R/etc/Makeconf:184: recipe for target 'biv-nt.o' failed

... but I'm guessing that conda install gfortran_linux-64 or conda install -c tsnyder gfortran_linux-cos6-x86_64 should fix it.

Thanks again for the help!

nick-youngblut commented Nov 11, 2017

Sorry for asking in the wrong spot. Thanks for the clarification. For what it's worth, running the following fixed the issue:

conda install gcc_linux-64
conda install gxx_linux-64

I still get an error when installing the mnormt package:

/ebio/abt3_projects/software/dev/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gfortran   -fpic  -fopenmp -march=
nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/ebio/abt3_projects
/software/dev/miniconda3/include -L/ebio/abt3_projects/software/dev/miniconda3/lib  -c biv-nt.f -o biv-nt.o
make: /ebio/abt3_projects/software/dev/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gfortran: Command not found
/ebio/abt3_projects/software/dev/miniconda3/lib/R/etc/Makeconf:184: recipe for target 'biv-nt.o' failed

... but I'm guessing that conda install gfortran_linux-64 or conda install -c tsnyder gfortran_linux-cos6-x86_64 should fix it.

Thanks again for the help!

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 11, 2017

Contributor

I would not encourage people to search for packages using anaconda and install them from users they do not know. If you know and trust tsnyder and he recommended you to install his packages for specific reasons then great, but otherwise avoid installing random packages.

conda install gfortran_linux-64 will get the gfortran package we (the Anaconda Distribution team) built (provided you've not customised your channels in ~/.condarc that is).

Contributor

mingwandroid commented Nov 11, 2017

I would not encourage people to search for packages using anaconda and install them from users they do not know. If you know and trust tsnyder and he recommended you to install his packages for specific reasons then great, but otherwise avoid installing random packages.

conda install gfortran_linux-64 will get the gfortran package we (the Anaconda Distribution team) built (provided you've not customised your channels in ~/.condarc that is).

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

Good point. conda install gfortran_linux-64 seems to have worked for installing the mnormt R package

nick-youngblut commented Nov 11, 2017

Good point. conda install gfortran_linux-64 seems to have worked for installing the mnormt R package

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

I think that I spoke too soon about fixing the issues. I can move this to a separate issue if needed. I installed the following:

conda install -c r r-base
conda install gcc_linux-64
conda install gxx_linux-64
conda install gfortran_linux-64

and this allowed me to install Rcpp, mnormt, etc. However, I'm getting issues when installing devtools or igraph (installing with install.packages()). For devtools, the error is:

* installing *source* package ‘openssl’ ...
** package ‘openssl’ successfully unpacked and MD5 sums checked
Found pkg-config cflags and libs!
Using PKG_CFLAGS=
src/tests/soname.h:1:10: fatal error: openssl/opensslv.h: No such file or directory
 #include "openssl/opensslv.h"

For igraph, the error is:

foreign-graphml.c: In function 'igraph_write_graph_graphml':
foreign-graphml.c:1408:46: error: expected ')' before 'GRAPHML_NAMESPACE_URI'
   ret=fprintf(outstream, "<graphml xmlns=\"" GRAPHML_NAMESPACE_URI "\"\n");
                                              ^~~~~~~~~~~~~~~~~~~~~
foreign-graphml.c:1412:59: error: expected ')' before 'GRAPHML_NAMESPACE_URI'
   ret=fprintf(outstream, "         xsi:schemaLocation=\"" GRAPHML_NAMESPACE_URI "\n");
                                                           ^~~~~~~~~~~~~~~~~~~~~
foreign-graphml.c:1414:38: error: expected ')' before 'GRAPHML_NAMESPACE_URI'
   ret=fprintf(outstream, "         " GRAPHML_NAMESPACE_URI "/1.0/graphml.xsd\">\n");
                                      ^~~~~~~~~~~~~~~~~~~~~
/ebio/abt3_projects/software/dev/miniconda3/envs/py2/lib/R/etc/Makeconf:160: recipe for target 'foreign-graphml.o' failed

I'm not sure if I have to install something else via conda to get these R packages to install properly.

nick-youngblut commented Nov 11, 2017

I think that I spoke too soon about fixing the issues. I can move this to a separate issue if needed. I installed the following:

conda install -c r r-base
conda install gcc_linux-64
conda install gxx_linux-64
conda install gfortran_linux-64

and this allowed me to install Rcpp, mnormt, etc. However, I'm getting issues when installing devtools or igraph (installing with install.packages()). For devtools, the error is:

* installing *source* package ‘openssl’ ...
** package ‘openssl’ successfully unpacked and MD5 sums checked
Found pkg-config cflags and libs!
Using PKG_CFLAGS=
src/tests/soname.h:1:10: fatal error: openssl/opensslv.h: No such file or directory
 #include "openssl/opensslv.h"

For igraph, the error is:

foreign-graphml.c: In function 'igraph_write_graph_graphml':
foreign-graphml.c:1408:46: error: expected ')' before 'GRAPHML_NAMESPACE_URI'
   ret=fprintf(outstream, "<graphml xmlns=\"" GRAPHML_NAMESPACE_URI "\"\n");
                                              ^~~~~~~~~~~~~~~~~~~~~
foreign-graphml.c:1412:59: error: expected ')' before 'GRAPHML_NAMESPACE_URI'
   ret=fprintf(outstream, "         xsi:schemaLocation=\"" GRAPHML_NAMESPACE_URI "\n");
                                                           ^~~~~~~~~~~~~~~~~~~~~
foreign-graphml.c:1414:38: error: expected ')' before 'GRAPHML_NAMESPACE_URI'
   ret=fprintf(outstream, "         " GRAPHML_NAMESPACE_URI "/1.0/graphml.xsd\">\n");
                                      ^~~~~~~~~~~~~~~~~~~~~
/ebio/abt3_projects/software/dev/miniconda3/envs/py2/lib/R/etc/Makeconf:160: recipe for target 'foreign-graphml.o' failed

I'm not sure if I have to install something else via conda to get these R packages to install properly.

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 11, 2017

Contributor

conda install -c r r-base

You do not need to specify -c r here anymore. r is now one of the default channels.

The Anaconda Distribution precompiles a lot of R packages so you don't need to:

conda install r-rcpp r-devtools r-igraph

In general if you want to compile things for yourself you need to be pretty software-building-savvy I am afraid and I wouldn't really recommend the 'standard' R approach of install.packages() because frankly IMHO it's a mess.

In the openssl case, you are missing the conda openssl package in your py2 env, I guess.

If you really do want to compile R packages from source you should use conda-build to generate recipes and then build those (conda skeleton cran igraph, then conda-build r-igraph for example). You need to pay attention to the SystemRequirements: section though and add the appropriate conda package to the requirements/build and or requirements/run sections in the generated meta.yaml.

I am considering modifying the Anaconda Distribution R's install.packages() to try installing a conda package first.

Contributor

mingwandroid commented Nov 11, 2017

conda install -c r r-base

You do not need to specify -c r here anymore. r is now one of the default channels.

The Anaconda Distribution precompiles a lot of R packages so you don't need to:

conda install r-rcpp r-devtools r-igraph

In general if you want to compile things for yourself you need to be pretty software-building-savvy I am afraid and I wouldn't really recommend the 'standard' R approach of install.packages() because frankly IMHO it's a mess.

In the openssl case, you are missing the conda openssl package in your py2 env, I guess.

If you really do want to compile R packages from source you should use conda-build to generate recipes and then build those (conda skeleton cran igraph, then conda-build r-igraph for example). You need to pay attention to the SystemRequirements: section though and add the appropriate conda package to the requirements/build and or requirements/run sections in the generated meta.yaml.

I am considering modifying the Anaconda Distribution R's install.packages() to try installing a conda package first.

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

Over the past year, myself and other members of my research group have had a bunch of issues when installing R packages via conda such as:

  • "package version not found" errors when trying to recreate environments from *.yaml files
  • Plotting in R didn't work because of issues with r-cairo
  • bioconductor packages like phyloseq fail when loading (eg., libicui18n.so.58: cannot open shared object)
  • some R packages are not available via conda, which leads to a strange (and often problematic) hybrid of using conda and install.packages()

For these reasons, we've switched to installing R packages whenever possible with install.packages(). At least up until recently, it's been a LOT less problematic than installing R packages with conda. It would be great to manage all software with conda, but with R packages, it's been a huge pain.

nick-youngblut commented Nov 11, 2017

Over the past year, myself and other members of my research group have had a bunch of issues when installing R packages via conda such as:

  • "package version not found" errors when trying to recreate environments from *.yaml files
  • Plotting in R didn't work because of issues with r-cairo
  • bioconductor packages like phyloseq fail when loading (eg., libicui18n.so.58: cannot open shared object)
  • some R packages are not available via conda, which leads to a strange (and often problematic) hybrid of using conda and install.packages()

For these reasons, we've switched to installing R packages whenever possible with install.packages(). At least up until recently, it's been a LOT less problematic than installing R packages with conda. It would be great to manage all software with conda, but with R packages, it's been a huge pain.

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 11, 2017

Contributor

I will attempt to fix any problem identified to me within the Anaconda Distribution. Let's take you points one at a time.

"package version not found" errors when trying to recreate environments from *.yaml files

You are over-pinning here I guess. How did you generate the environment.yaml files? I personally do not like this approach since it probably pins exact build numbers (so you will not get bug fixes to builds) and doesn't record and re-use channel information. I would go for just conda install <r-blah> <r-blah2> <r-blah3> instead. If you do want exact versions then you need to be careful to have the exact same channels in your ~/.condarc as where you generated the environment.yaml. Pinging @kalefranz to fact check this as, as I say, I have never used this feature.

Plotting in R didn't work because of issues with r-cairo

This has been fixed for a long time.

bioconductor packages like phyloseq fail when loading (eg., libicui18n.so.58: cannot open shared object)

I assume you meant bioconductor packages installed from the bioconda or conda-forge channel(s) here? I have only very limited influence over conda-forge and bioconda. They are currently carrying broken packages I am afraid. We (the Anaconda Distribution team) are trying to attain binary compatibility with them which would include alignment of our shared library versions but we are not there yet.

some R packages are not available via conda, which leads to a strange (and often problematic) hybrid of using conda and install.packages()

You are best off building conda binary R packages the way we (Anaconda Distribution and conda-forge) do and if you run into any problems with that approach then I am more than happy to help out. You can then host such packages on anaconda.org so that other team members can re-use them.

Contributor

mingwandroid commented Nov 11, 2017

I will attempt to fix any problem identified to me within the Anaconda Distribution. Let's take you points one at a time.

"package version not found" errors when trying to recreate environments from *.yaml files

You are over-pinning here I guess. How did you generate the environment.yaml files? I personally do not like this approach since it probably pins exact build numbers (so you will not get bug fixes to builds) and doesn't record and re-use channel information. I would go for just conda install <r-blah> <r-blah2> <r-blah3> instead. If you do want exact versions then you need to be careful to have the exact same channels in your ~/.condarc as where you generated the environment.yaml. Pinging @kalefranz to fact check this as, as I say, I have never used this feature.

Plotting in R didn't work because of issues with r-cairo

This has been fixed for a long time.

bioconductor packages like phyloseq fail when loading (eg., libicui18n.so.58: cannot open shared object)

I assume you meant bioconductor packages installed from the bioconda or conda-forge channel(s) here? I have only very limited influence over conda-forge and bioconda. They are currently carrying broken packages I am afraid. We (the Anaconda Distribution team) are trying to attain binary compatibility with them which would include alignment of our shared library versions but we are not there yet.

some R packages are not available via conda, which leads to a strange (and often problematic) hybrid of using conda and install.packages()

You are best off building conda binary R packages the way we (Anaconda Distribution and conda-forge) do and if you run into any problems with that approach then I am more than happy to help out. You can then host such packages on anaconda.org so that other team members can re-use them.

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

Thank you for your help with all of these issues. Sorry to be such a pain, but I've spent most of my day trying to figure out how to reconfigure my group's conda environments, which incorporate python, jupyter, R, and a lot of bioinformatics software. Our previous method of installing jupyter & r-base with conda, then installing R packages via install.packages() has become very problematic recently.

In regards to recreating conda environments, I haven't tried recently, so I don't know if this problem still exists, but it made us weary of using conda to install R packages if we couldn't reproduce the environment from a *.yaml file.

The r-cairo issue is old, but again, it made us weary of using conda for installing R packages.

Yes, I did mean installing bioconductor packages with conda. Given that some package installations are broken and some are not available via conda, we often have to use install.packages(). We didn't know about building conda binary R packages, but that would have to be done repeatedly each time a package was updated on CRAN (if we want/need updated package versions), correct?

Also, members of my group that have limited computational skills will probably just keep using install.packages(), especially since documentation on installing R packages always suggests using install.packages() or biocLite() (eg., the Phyloseq package installation documentation)

I'm not sure what to do right now, given that I can't seem to install some R packages that are needed for our research. For instance, phyloseq is broken if installed via conda, but using install.packages() requires an igraph install (even if already installed via conda), and the igraph installation isn't working with install.packages(). I don't want to give up on managing R and R packages with conda, but we can't conduct our research without being able to properly manage installations of this software.

nick-youngblut commented Nov 11, 2017

Thank you for your help with all of these issues. Sorry to be such a pain, but I've spent most of my day trying to figure out how to reconfigure my group's conda environments, which incorporate python, jupyter, R, and a lot of bioinformatics software. Our previous method of installing jupyter & r-base with conda, then installing R packages via install.packages() has become very problematic recently.

In regards to recreating conda environments, I haven't tried recently, so I don't know if this problem still exists, but it made us weary of using conda to install R packages if we couldn't reproduce the environment from a *.yaml file.

The r-cairo issue is old, but again, it made us weary of using conda for installing R packages.

Yes, I did mean installing bioconductor packages with conda. Given that some package installations are broken and some are not available via conda, we often have to use install.packages(). We didn't know about building conda binary R packages, but that would have to be done repeatedly each time a package was updated on CRAN (if we want/need updated package versions), correct?

Also, members of my group that have limited computational skills will probably just keep using install.packages(), especially since documentation on installing R packages always suggests using install.packages() or biocLite() (eg., the Phyloseq package installation documentation)

I'm not sure what to do right now, given that I can't seem to install some R packages that are needed for our research. For instance, phyloseq is broken if installed via conda, but using install.packages() requires an igraph install (even if already installed via conda), and the igraph installation isn't working with install.packages(). I don't want to give up on managing R and R packages with conda, but we can't conduct our research without being able to properly manage installations of this software.

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 11, 2017

Contributor

Yes, I did mean installing bioconductor packages with conda

bioconductor is separate from bioconda. bioconda packages bioconductor software (and more). You need to be clear about where you installed broken or incompatible software from, i.e. did you use conda install -c bioconda phyloseq?)

IMHO something needs to be done upstream in the R project to fix the status quo. CRAN has had binary packages for Windows for a long time and now they've started to do that for macOS too (since 3.4), however they only support macOS 10.11 and above while we support macOS 10.9 and above. Many R packages also use something called autobrew on macOS for people who attempt to build from source. This doesn't really build from source, instead it partially builds from source, fetching static system libraries as binary bottles from Homebrew. For Linux, there are no binaries and it is up to the end-user to have the correct software (compilers and system libraries) installed. This is not something that is going to end well in general. It requires everyone using R on Linux to be an expert at software compilation and packaging.

We are actively thinking about this but have nothing to report. I honestly do believe our way is the least trouble, provided you stick to the defaults channels only and use conda skeleton cran to build the missing packages.

We didn't know about building conda binary R packages, but that would have to be done repeatedly each time a package was updated on CRAN (if we want/need updated package versions), correct?

I only do full build-outs of all of our R packages at each release of the R interpreter that we bundle. For most people there's no strong need to have the latest and greatest of everything all the time. If you need a new feature in the latest version of a package, well, you'll know about that.

Contributor

mingwandroid commented Nov 11, 2017

Yes, I did mean installing bioconductor packages with conda

bioconductor is separate from bioconda. bioconda packages bioconductor software (and more). You need to be clear about where you installed broken or incompatible software from, i.e. did you use conda install -c bioconda phyloseq?)

IMHO something needs to be done upstream in the R project to fix the status quo. CRAN has had binary packages for Windows for a long time and now they've started to do that for macOS too (since 3.4), however they only support macOS 10.11 and above while we support macOS 10.9 and above. Many R packages also use something called autobrew on macOS for people who attempt to build from source. This doesn't really build from source, instead it partially builds from source, fetching static system libraries as binary bottles from Homebrew. For Linux, there are no binaries and it is up to the end-user to have the correct software (compilers and system libraries) installed. This is not something that is going to end well in general. It requires everyone using R on Linux to be an expert at software compilation and packaging.

We are actively thinking about this but have nothing to report. I honestly do believe our way is the least trouble, provided you stick to the defaults channels only and use conda skeleton cran to build the missing packages.

We didn't know about building conda binary R packages, but that would have to be done repeatedly each time a package was updated on CRAN (if we want/need updated package versions), correct?

I only do full build-outs of all of our R packages at each release of the R interpreter that we bundle. For most people there's no strong need to have the latest and greatest of everything all the time. If you need a new feature in the latest version of a package, well, you'll know about that.

@nick-youngblut

This comment has been minimized.

Show comment
Hide comment
@nick-youngblut

nick-youngblut Nov 11, 2017

Sorry for not being clear about the phyloseq install. I installed it from bioconda.

I appreciate all that you and others are doing with conda to create a powerful tool for managing python & other software, which greatly helps with performing reproducible bioinformatics (& data science in general).

With that said, I currently can't get some R packages installed with install.packages() (due to the compiling errors) and those packages are either not available via conda or the conda install is broken. Compiling R packages and posting them to anaconda.org could help, but this potentially produces a lot of work for my group (if many packages must be maintained due to dependencies with various bioinformatics software relying on specific package versions), and many in my group will probably argue that it will be better to just switch to local installs of R outside of conda, and keep R completely separate from conda. That is, if we could figure out how to keep R separate from conda, but still use R kernels & rpy2 with Jupyter.

It's too bad (and really frustrating) that there's such a divide between python and R (eg., Rstudio doesn't support python; Jupyter doesn't work natively with R & CRAN; not all R packages are supported by conda). This leaves bioinformaticians and data scientists trying to span the divide, and not always successfully.

nick-youngblut commented Nov 11, 2017

Sorry for not being clear about the phyloseq install. I installed it from bioconda.

I appreciate all that you and others are doing with conda to create a powerful tool for managing python & other software, which greatly helps with performing reproducible bioinformatics (& data science in general).

With that said, I currently can't get some R packages installed with install.packages() (due to the compiling errors) and those packages are either not available via conda or the conda install is broken. Compiling R packages and posting them to anaconda.org could help, but this potentially produces a lot of work for my group (if many packages must be maintained due to dependencies with various bioinformatics software relying on specific package versions), and many in my group will probably argue that it will be better to just switch to local installs of R outside of conda, and keep R completely separate from conda. That is, if we could figure out how to keep R separate from conda, but still use R kernels & rpy2 with Jupyter.

It's too bad (and really frustrating) that there's such a divide between python and R (eg., Rstudio doesn't support python; Jupyter doesn't work natively with R & CRAN; not all R packages are supported by conda). This leaves bioinformaticians and data scientists trying to span the divide, and not always successfully.

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Nov 11, 2017

Contributor

With that said, I currently can't get some R packages installed with install.packages() (due to the compiling errors) and those packages are either not available via conda or the conda install is broken

The thing is, the problems you described with install.packages() on Linux are not to do with conda. You need to install toolchains and system packages (when using conda via conda install, when using some other Linux distro via apt-get install or dnf install) so I don't think 'local installs of R outside of conda' will be any easier, ok, you might already have those toolchains and system packages installed on your system but that just leads to non-explicit dependency management (which conda always avoids) and problems when people without those system packages (or different versions of them) try to repeat what you built.

For managing R packages on Linux, my opinion is that CRAN is worse than conda because at least with conda we have built as binaries, ensured good iterop with Python and occasionally bug-fixed the build system for 340 odd R packages in a very compatible way (i.e. across different versions of our host OSes) so that you do not have to.

If you do decide to explore conda skeleton cran I am happy to assist.

Contributor

mingwandroid commented Nov 11, 2017

With that said, I currently can't get some R packages installed with install.packages() (due to the compiling errors) and those packages are either not available via conda or the conda install is broken

The thing is, the problems you described with install.packages() on Linux are not to do with conda. You need to install toolchains and system packages (when using conda via conda install, when using some other Linux distro via apt-get install or dnf install) so I don't think 'local installs of R outside of conda' will be any easier, ok, you might already have those toolchains and system packages installed on your system but that just leads to non-explicit dependency management (which conda always avoids) and problems when people without those system packages (or different versions of them) try to repeat what you built.

For managing R packages on Linux, my opinion is that CRAN is worse than conda because at least with conda we have built as binaries, ensured good iterop with Python and occasionally bug-fixed the build system for 340 odd R packages in a very compatible way (i.e. across different versions of our host OSes) so that you do not have to.

If you do decide to explore conda skeleton cran I am happy to assist.

@pengjingg

This comment has been minimized.

Show comment
Hide comment
@pengjingg

pengjingg Nov 15, 2017

I encountered this problem while installing cupy, I tried downgrade conda to several versions(including 4.3.24, 4.3.25, 4.3.27) but none of them works. My original conda version is 4.3.30 by the way. So I upgrade conda back to 4.3.30 and run command "conda update python" and it finally worked out !!!
(system: ubuntu 16.04LTS; cuda: 9.0)
2017.11.15

pengjingg commented Nov 15, 2017

I encountered this problem while installing cupy, I tried downgrade conda to several versions(including 4.3.24, 4.3.25, 4.3.27) but none of them works. My original conda version is 4.3.30 by the way. So I upgrade conda back to 4.3.30 and run command "conda update python" and it finally worked out !!!
(system: ubuntu 16.04LTS; cuda: 9.0)
2017.11.15

@armaneshaghi

This comment has been minimized.

Show comment
Hide comment
@armaneshaghi

armaneshaghi Dec 6, 2017

I have the same issue with the latest Anaconda (downloaded today) when installing new packages in R.

armaneshaghi commented Dec 6, 2017

I have the same issue with the latest Anaconda (downloaded today) when installing new packages in R.

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Dec 6, 2017

Contributor

@armaneshaghi what issue? You need to install our compilers. The package is called gxx_linux-64.

Contributor

mingwandroid commented Dec 6, 2017

@armaneshaghi what issue? You need to install our compilers. The package is called gxx_linux-64.

@armaneshaghi

This comment has been minimized.

Show comment
Hide comment
@armaneshaghi

armaneshaghi Dec 6, 2017

@mingwandroid thanks for the response, conda install gxx_linux-64 solved my issue. I just wonder why this is no longer automatic for naive users (like me)?

armaneshaghi commented Dec 6, 2017

@mingwandroid thanks for the response, conda install gxx_linux-64 solved my issue. I just wonder why this is no longer automatic for naive users (like me)?

@mingwandroid

This comment has been minimized.

Show comment
Hide comment
@mingwandroid

mingwandroid Dec 6, 2017

Contributor

Historically we didn't provide any compilers, then we provided old ones but our R packages didn't use the those old ones instead relying on system ones (when you use install.packages()). That brings it's own problems (I don't know how capable your system ones are and anything you build with them will likely not work on other systems and loading R packages built with them could prevent binaries we built from loading or working).

Forcing our compilers on everyone who installs R on Linux might be the best plan though, but actually upstream R is moving towards providing prebuilt binaries (at least for Windows and macOS).

The other complication is that you are better off not using install.packages() for most things since we already provide prebuilt binary conda packages for a lot of the most popular R packages, so conda install r-something is better.

I am considering to patch install.packages() so that it tries installing a conda package first, and failing that, installs compilers if necessary before running the normal code-path.

Overall it's very difficult to know what is best here!

Contributor

mingwandroid commented Dec 6, 2017

Historically we didn't provide any compilers, then we provided old ones but our R packages didn't use the those old ones instead relying on system ones (when you use install.packages()). That brings it's own problems (I don't know how capable your system ones are and anything you build with them will likely not work on other systems and loading R packages built with them could prevent binaries we built from loading or working).

Forcing our compilers on everyone who installs R on Linux might be the best plan though, but actually upstream R is moving towards providing prebuilt binaries (at least for Windows and macOS).

The other complication is that you are better off not using install.packages() for most things since we already provide prebuilt binary conda packages for a lot of the most popular R packages, so conda install r-something is better.

I am considering to patch install.packages() so that it tries installing a conda package first, and failing that, installs compilers if necessary before running the normal code-path.

Overall it's very difficult to know what is best here!

jwjohnson314 pushed a commit to jwjohnson314/scikit-learn that referenced this issue Dec 18, 2017

alexlib added a commit to alexlib/dockerfiles that referenced this issue Jan 9, 2018

Update Dockerfile
read something on this one, not sure it's the right solution, going to test ,conda/conda#6030

@alexlib alexlib referenced this issue Jan 9, 2018

Merged

Update Dockerfile #2

@corytu

This comment has been minimized.

Show comment
Hide comment
@corytu

corytu Feb 25, 2018

@mingwandroid some research on the Internet led me here. I am facing difficulties when installing R packages just like @nick-youngblut did. I see your suggestion for using conda skeleton cran approach instead of using R function install.packages, and I have done conda install gxx_linux-64. However, I keep failing at the conda build step.

Specifically, I want to install an R package called "RPostgreSQL", and here is what I have done:

conda install gxx_linux-64
conda skeleton cran r-rpostgresql
conda build r-rpostgresql
# I also tried:
# conda build --R 3.4.2 r-rpostgresql
# conda build --R=3.4.2 r-rpostgresql

The error includes:

make: /home/ytu/anaconda3/conda-bld/r-rpostgresql_1519544237983/h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/x86_64-conda_cos6-linux-gnu-cc: Command not found

, and

make: *** [/home/ytu/anaconda3/conda-bld/r-rpostgresql_1519544237983/h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/R/etc/Makeconf:160: RS-DBI.o] Error 127
ERROR: compilation failed for package ‘RPostgreSQL’

, and finally

subprocess.CalledProcessError: Command '['/bin/bash', '-e', '/home/ytu/anaconda3/conda-bld/r-rpostgresql_1519544237983/work/conda_build.sh']' returned non-zero exit status 1.

You could find some other information in my question on Stack Overflow: Installing packages in IRkernel on Jupyter Notebook.

How should I do to solve this?

corytu commented Feb 25, 2018

@mingwandroid some research on the Internet led me here. I am facing difficulties when installing R packages just like @nick-youngblut did. I see your suggestion for using conda skeleton cran approach instead of using R function install.packages, and I have done conda install gxx_linux-64. However, I keep failing at the conda build step.

Specifically, I want to install an R package called "RPostgreSQL", and here is what I have done:

conda install gxx_linux-64
conda skeleton cran r-rpostgresql
conda build r-rpostgresql
# I also tried:
# conda build --R 3.4.2 r-rpostgresql
# conda build --R=3.4.2 r-rpostgresql

The error includes:

make: /home/ytu/anaconda3/conda-bld/r-rpostgresql_1519544237983/h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/x86_64-conda_cos6-linux-gnu-cc: Command not found

, and

make: *** [/home/ytu/anaconda3/conda-bld/r-rpostgresql_1519544237983/h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/R/etc/Makeconf:160: RS-DBI.o] Error 127
ERROR: compilation failed for package ‘RPostgreSQL’

, and finally

subprocess.CalledProcessError: Command '['/bin/bash', '-e', '/home/ytu/anaconda3/conda-bld/r-rpostgresql_1519544237983/work/conda_build.sh']' returned non-zero exit status 1.

You could find some other information in my question on Stack Overflow: Installing packages in IRkernel on Jupyter Notebook.

How should I do to solve this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment