Open schuelet opened 2 years ago
name: fsk_r_static_351 channels: # Repositories to search for packages
Here are yml files for different operating systems, there are subtle differences between them. When an update is made, we will upload them in a new comment. MacOS: https://app.zenhub.com/files/241333403/34ca7488-5b4b-4a78-96cb-2e01e2cd068d/download Windows: https://app.zenhub.com/files/241333403/e3d0eaf1-5bf4-4112-a72f-1d36e0cec3e3/download Linux: https://app.zenhub.com/files/241333403/a2b8a857-79ea-4fc6-9c40-4bb9782144d9/download
@schuelet Why didn't you include all the package versions which can be installed I have figured out, added and send to you? We should make sure to have the exact same environment on all systems and this is one step towards it.
@llavall I am still testing and need to change versions accordingly. For example, under Windows, tidyverse needs to be 1.3.0, maybe there will be need to change versions on Linux as well. Once it works, I will add the version numbers.
@llavall @schuelet:
creating the environment using multiple channels could break them. I had problem with loading the Cairo library on Mac os.
Fehler: package or namespace load failed for ‘Cairo’: .onLoad in loadNamespace() für 'Cairo' fehlgeschlagen, Details: Aufruf: dyn.load(file, DLLpath = DLLpath, ...) Fehler: kann shared object '/Users/user/opt/anaconda3/envs/fsk_r_static_351/lib/R/library/Cairo/libs/Cairo.so' nicht laden: dlopen(/Users/user/opt/anaconda3/envs/fsk_r_static_351/lib/R/library/Cairo/libs/Cairo.so, 6): Library not loaded: @rpath/libfontconfig.1.dylib Referenced from: /Users/ahmadswaid/opt/anaconda3/envs/fsk_r_static_351/lib/libcairo.2.dylib Reason: Incompatible library version: libcairo.2.dylib requires version 14.0.0 or later, but libfontconfig.1.dylib provides version 13.0.0
This was solved by creating the same environment but using only one channel. What is the use case of using multiple channels?
@ahmadswaid not all packages might be available on just one channel and we would need to jump through quite some loops in order to contribute to conda-forge. I hope by specifying the versions of the packages and syncing our conda versions(I just learned, that the most recent anaconda on Windows installs R a bit differently) we can avoid these incongruent behaviors on our systems. @llavall was absolutely right to have the versions added to the yml files, I underestimated the potential conflicts.
Executor preferences (Example) /instance/de.bund.bfr.knime.fsklab.preferences/conda.path=/home/knime/miniconda3 /instance/de.bund.bfr.knime.fsklab.preferences/python2.env=/home/knime/miniconda3/envs/py2_knime_2 /instance/de.bund.bfr.knime.fsklab.preferences/python3.env=/home/knime/miniconda3/envs/py3_knime_1 /instance/de.bund.bfr.knime.fsklab.preferences/r.env=/home/knime/miniconda3/envs/fsk_r_static_351 /instance/de.bund.bfr.knime.fsklab.preferences/r3.path=/usr/lib/R
update: Linux: https://app.zenhub.com/files/241333403/eb3193fc-4089-4f7d-9444-ebbdaa59ae37/download
I have added all missing conda files to our new FSKX Conda-Channel https://anaconda.org/fskx/repo
Here is the resulting new .yml file to consider the new sources:
name: fsk_r_static_351 channels: # Repositories to search for packages