If you want to cater for a more heterogeneous environment, then an alternative approach would be to use conda. One thing worth mentioning is that the above is aimed at a rather homogeneous environment, where the same operating system is in use on all the client machines. The http server itself is simply serving static content, so does not need special configuration.įor Ubuntu etc, you could do similarly but with deb packages and APT.
#PIP INSTALL GFORTRAN UPDATE#
Any subsequent yum update on the clients will pick up any changes that you push to your repository.
#PIP INSTALL GFORTRAN PLUS#
base and EPEL) plus any other RPMs that you need to build locally, publish it to the repository on the http server and use createrepo to construct the necessary repository metadata, and create a config file in /etc/ on the clients to point to your repository and run yum install. The above is in general terms, but taking the specific example on which this experience is based, if the client machines are running CentOS, then you would create a meta-RPM with dependencies on packages in standard repositories (e.g.
#PIP INSTALL GFORTRAN SOFTWARE#
This is from experience where this approach has worked well in setting up and maintaining a common software platform across a large number of machines (including nodes of a compute cluster) - although in cases where the required software components are not available in standard package repositories, it is then necessary to build a package for it locally and publish that to your repository this can then be added as a requirement in your metapackage. For the individual software components listed in the metapackage, the software update will pick up any updates to these in the ordinary way, provided that the dependency information in the metapackage does not specify an exact version (you could make the metapackage depend on >= some version number). If you also set up a repository on an http server containing your metapackage, and configure the package manager on the clients to point to it, then if you later decide to update the list of packages contained in your standard software suite across all the client machines, all you need to do is to publish a new version of your metapackage to the repository, and have the client machines rerun their operating system's software updater. (A metapackage is one which does not directly contain any software itself but which lists a number of dependencies that the package manager will need to satisfy when installing it.) will install gfortran (You may need to be logged in as root.) In order to link with python and use pip, you will also need: yum install python-devel yum install python-pip OR sudo yum install python-devel sudo yum install python-pip. If you are having trouble with installing things with pip due to disk/folder permissions, try adding -user to the pip flags in order to install modules to a local directory. python3 -m pip install pybind11 sphinx sphinx-autodoc-typehints.
If the packages that you want are available for installation via the standard package manager for the Linux distribution that you are using, you could build a metapackage which, when installed, will force the installation of all of the components. yum install epel-release yum install gcc-gfortran. NOTE: On any distro, you can install pybind11, Sphinx, and related modules directly through pip. A possible different approach to consider.
0 kommentar(er)
