CI.yml and environment.yml updates to run CI on MacOS and Ubuntu
#2415
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,54 +1,118 @@ | ||
| # environment.yml - conda environment specification file for RMG-Py | ||
| # | ||
| # Usage: conda env create --file environment.yml | ||
| # | ||
| # This file contains all of the software packages needed to run RMG-Py. | ||
| # There is a mixture of the following | ||
| # - packlages would could be installed at OS level, but we install here | ||
| # for better version control | ||
| # - python tools | ||
| # - external software tools specific to chemistry | ||
| # - other software we maintain which RMG depends on | ||
| # + some other categories (see below) | ||
| # | ||
| # Changelog: | ||
| # - May 15, 2023 Added this changelog, added inline documentation, | ||
|
Member
There was a problem hiding this comment. I'm torn about introducing a changelog, since one could always do
Contributor
Author
There was a problem hiding this comment. The way I see changelogs is that they provide a "high-level" perspective on how the file has changed over time. The git log is useful for fixing technical issues and precise problems with specific lines, but I think the changelog is better for answering questions like "why do we have some packages from this channel but other from this one" or the like.
|
||
| # made depdency list more explicit (@JacksonBurns). | ||
| # | ||
| name: rmg_env | ||
| channels: | ||
| - defaults | ||
| - rmg | ||
| - conda-forge | ||
| - cantera | ||
| dependencies: | ||
| # System-level dependencies - we could install these at the OS level | ||
| # but by installing them in the conda environment we get better control | ||
| - cairo | ||
| - cairocffi | ||
| - ffmpeg | ||
| - xlrd | ||
| - xlwt | ||
| - h5py | ||
| - graphviz | ||
| - markupsafe | ||
| - psutil | ||
| # conda-forge not default, since default has a version information bug | ||
| # (see https://github.com/ReactionMechanismGenerator/RMG-Py/pull/2421) | ||
| - conda-forge::ncurses | ||
| - conda-forge::suitesparse | ||
|
|
||
| # external software tools for chemistry | ||
| - coolprop | ||
| - cantera::cantera=2.6 | ||
| - conda-forge::mopac | ||
| - conda-forge::cclib >=1.6.3 | ||
| - conda-forge::openbabel >= 3 | ||
|
|
||
| # general-purpose external software tools | ||
| - conda-forge::julia>=1.8.5 | ||
|
|
||
| # Python tools | ||
| - python >=3.7 | ||
| - coverage | ||
| - cython >=0.25.2 | ||
| - scikit-learn | ||
| - scipy | ||
| - numpy >=1.10.0 | ||
| - pydot | ||
| - jinja2 | ||
| - jupyter | ||
| - pymongo | ||
| - pyparsing | ||
| - pyyaml | ||
| - networkx | ||
| - nose | ||
| - matplotlib >=1.5 | ||
| - mpmath | ||
| - pandas | ||
|
|
||
| # packages we maintain | ||
| - rmg::gprof2dot | ||
| - rmg::lpsolve55 | ||
| - rmg::muq2 | ||
| - rmg::numdifftools | ||
| - rmg::pydas >=1.0.3 | ||
| - rmg::pydqed >=1.0.3 | ||
|
Member
There was a problem hiding this comment. Is pyjulia installed through
Contributor
Author
There was a problem hiding this comment. It's not, and the rmg:pyjulia does not either. The conda-recipes repo has the build script and you can see that it only provides Julia (as far as I can tell, I'm new to building conda packages). I think pyjulia is an implicit dependency of something else in the environments file? So it is added when the environment is solved?
Member
There was a problem hiding this comment. So, correct if I am misunderstanding what you are saying, but we will need to keep pyjulia as it is the connection between Julia and Python. So I guess we can either keep getting from the rmg channel or from conda-forge channel. However, the CI appears to be passing? I am a bit confused though how it is doing that when pyjulia isn't installed in the rmg_env (I am assuming here or really misunderstanding something)
Contributor
Author
There was a problem hiding this comment.
My mistake - conda still ends up retrieving pyjulia from the rmg channel. See this line in the latest CI run. CC'ing @mjohnson541 - pyjulia, how does it work? The conda-recipe doesn't make sense to us.
Member
There was a problem hiding this comment. So my understanding of PyJulia is that, assuming you have Julia installed and set in the PATH (or set in our conda env path for our case when rmg_env is active), it is imported in python like so: import juliaThen we use PyJulia for the We can also use PyJulia to create our system images for precompiling
Member
There was a problem hiding this comment. Apologies if that was already understood
Contributor
There was a problem hiding this comment. It is a dependency of pyrms and diffeqpy which causes it to be installed as well. |
||
| - rmg::pyrdl | ||
| - rmg::pyrms | ||
| - rmg::quantities | ||
| - rmg::symmetry | ||
|
|
||
| # packages we would like to stop maintaining (and why) | ||
| - rmg::diffeqpy | ||
| # we should use the official verison https://github.com/SciML/diffeqpy), | ||
| # rather than ours (which is only made so that we can get it from conda) | ||
| # It is only on pip, so we will need to do something like: | ||
| # https://stackoverflow.com/a/35245610 | ||
|
|
||
| - rmg::chemprop | ||
| # Our build of this is version 0.0.1 (!!) and we are using parts | ||
| # of the API that are now gone. Need a serious PR to fix this. | ||
|
|
||
| - rmg::rdkit >=2020.03.3.0 | ||
| # We should use the official channel, not sure how difficult this | ||
| # change will be. | ||
|
|
||
| - rmg::pyjulia | ||
| # This is identical to the conda-forge package, except that we run | ||
| # a hard to decipher sed command during the build process: | ||
| # https://github.com/ReactionMechanismGenerator/conda-recipes/blob/rmg-deps/pyjulia/build.sh#LL15C69-L15C69 | ||
| # | ||
| # We should either remove the need to use this command or add this | ||
| # to the installation steps | ||
| # | ||
| # Both pyrms and diffeqpy depend on this package. | ||
|
|
||
| # conda mutex metapackage | ||
| - nomkl | ||
|
|
||
| # additional packages that are required, but not specified here (and why) | ||
| # pydqed, pydas, mopac, and likely others require a fortran compiler (specifically gfortran) | ||
| # in the environment. Normally we would add this to the environment file with | ||
| # - libgfortran-ng >= 10 | ||
| # but this exact package is only maintained for Linux, meaning that if we were to add | ||
| # it here the environment creation would fail on Mac. The way it ends up working behind | ||
| # the scenes is that conda will find a different package for Mac that provides gfortran, | ||
| # but because we cannot specify per-platform requirements in this file we simply leave | ||
| # it out. | ||
Uh oh!
There was an error while loading. Please reload this page.