Python packages can be installed via system packages managers (e.g., apt) or through dedicated managers (e.g., pip). Consider installing a system package that depends on python packages. What is the best practice on managing python dependencies of system packages? As I see it, there are two possibilities:
The manager (apt-like) simply installs what it needs, which may cause python package duplication, e.g., the user already installed say numpy through pip which apt does not detect and will also install numpy, which may cause version conflicts among other issues;
The manager (apt-like) has to check if the dependency packages were installed by some other manager, which may cause version issues later on if an apt package requires updated versions of python packages, which will not be handled by apt.
Related
Scenario: new installation of plesk 12.5 on centOS 7 into an OpenVZ container (proxmox):
Installing Plesk 12.5 I get the following error:
Exception: Failed to solve dependencies: 1:perl-JSON-XS-2.27-2.el6.x86_64 requires perl(:MODULE_COMPAT_5.10.1)
any tips?
You mention CentOS 7, but the package you are attempting to install (perl-JSON-XS-2.27-2.el6.x86_64) is for RedHat/CentOS 6, denoted by the el6 tag in the package name.
In any case, the issue appears to be due to not having the correct repositories available in yum to solve all necessary dependencies. Plesk maintains their own yum repositories to provide all of the necessary packages. Usually the install script will handle this for you (the install script is just a quick way to obtain the Plesk autoinstaller which should have the proper source repository configured).
I would suggest you examine the currently configured yum repositories in your container and make sure there are no conflicting repositories. Depending on the components you are installing with Plesk, it will want to manage nginx, apache, mysql, php, and some perl components so make sure you do not have yum repositories attempting to install related packages. Also, if you are indeed using CentOS 7, make sure you have no repositories attempting to install CentOS 6 packages. This bash one-liner should print out all the configured yum repository URLs so you can quickly scan if any are using the wrong version:
grep -re '^\(mirrorlist\|baseurl\)' /etc/yum.repos.d/
If you need further troubleshooting help, please include how you are attempting to install Plesk.
We have been testing with Platform.sh this weekend, which uses debian as its OS. The deployment of the application was easy, until we started testing some of the core functionalities like creating a PDF.
The PDF is generated using wkhtmltopdf, which has different binaries depending on OS. Our own platform consists of CentOS7 machines, so we let composer install the Centos7 specific package: https://github.com/rvanlaak/wkhtmltopdf-amd64-centos7 For Debian this package is needed: https://github.com/h4cc/wkhtmltopdf-amd64
So basically the problem is the inconsistency in plaform. Saw that composer allows you to define specific versions for PHP and extensions, but config.platform unfortunately can not solve this problem.
Unfortunately the following hooks did resolve into a deployment error too:
composer remove rvanlaak/wkhtmltopdf-amd64-centos7 --no-update
composer require h4cc/wkhtmltopdf-amd64:~0.12 --no-update
composer update
As we can not choose the OS on platform.sh, how can we let composer check for a specific OS?
How to install rvm(ruby) on RHL7 using centos repo.
I know if we are using centos repository we should be using centos OS and not RedHat, but we have a proprietary software that require Redhat.
when I try to install ruby 1.93 using rvm I got this:
rvm install 1.9.3
Searching for binary rubies, this might take some time.
No binary rubies available for: redhat/6/x86_64/ruby-1.9.3-p551.
Continuing with compilation. Please read 'rvm help mount' to get more information on binary rubies.
Checking requirements for redhat.
Unable to locate SystemId file. Is this system registered?
Our client does not have registered system with redhat, So I did configure centos repository.
But how can I tell RVM to use this centos repository?
I managed the problem running:
rvm autolibs read-only
In that way rvm do not try to download the dependencies from redhat. But it tell us what is missing, so we can install what is missing manually with yum install from centos repository.
RedHat uses the concept of software collection to offer update packages for Ruby, Python, etc:
softwarecollections
For your case, they have software collection for Ruby193 and Ruby22.
On each page you will find instructions on how to use it.
I wonder if there are any options in Perl to build a local CPAN repository including the modules I want and then redistribute it with Perl distribution and then do not need to access CPAN at all.
If yes, could some me show an example?
I looked on CPAN and found a mincpan but it seems that minicpan bring all the mirror of CPAN. If it's possible to bring only a specific subset of modules using minicpan and in case I have a repository is it possible to copy it to another OS with the same type and install the relevant modules there with no headaches?
See Pinto (manages a local cpan-like repository) or Carton (can bundle up dependencies and provide them as needed, but you must run your application under carton after deployment.)
Alternatively, instead of a local minimal CPAN distribution, you can bundle requirements with your module, if you use the Module::Install installer.
The Pinto tools only work on Unix-like machines. However, Windows users can install modules from the repository as long as they can read the filesystem (like with NFS) or reach the host via HTTP (using pintod). So it is possible to use a Pinto repository with Windows, so long as you have one Unix-like machine to create and manage the repository.
Stratopan provides Pinto repositories hosted in the cloud. With Stratopan, you don't have to install any tools and everything can be managed through the browser. You can then install modules anywhere that has internet access using the standard tools. Stratopan doesn't yet support all the features Pinto has, but it is the most hassle-free solution for creating a private CPAN.
Disclaimer: I operate Stratopan.
This is addressed by How to mirror CPAN
What are the pros and cons of using Debian packages to deploy a web application as opposed to using Fabric? I have only ever used Debian packages.
I'm also interested in hearing about problems you've bumped into when using Fabric and you wished you had used Debian packages.
Debian
It is a Package Manager. It allows user to manage packages through various programs like dpkg or apt on a system.
What it does for you :
builds package from source
handles package dependencies, package versions
installs, updates and removes programs on a system
works at low level, compiled binaries maybe system specific (i386, amd64)
Cons :
To deploy the application the configuration must be provided in your package, or some configuration has to be used as default
Different binaries for systems with different architecture
Fabric
It is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.
What it does for you :
configure your system
execute commands on local/remote server (systems administration)
deploy your application, do rollbacks, mainly automate deployment through a script
works on a higher level, does not depend on system architecture but on OS and package manager
How do you use pip, virtualenv and Fabric to handle deployment?
Cons:
It cannot replace package manager on a system, it manages packages on top of it
You should know the system, commands folders specific to your package manager / OS
Update
I was already familiar with Debian when Fabric came. So Debian has stayed as my preferable tool. Why I use Fabric, it eases deployment of applications and is handy tool for developers. Here are some reasons why I would use Debian over Fabric:
When I am not going into production, still developing and testing stuff. Debian is suitable most of the time, when code is being added/modified. Fabric just eases the transition from development to production.
Sometimes if I deploy application on my machine only, Fabric seems overkill. If deployment does not involve many machines, requires several dependencies, I would stick to Debian.
When rollback, or undoing is not an option. Fabric will simply execute your commands safe or not, if you are not adept at handling system errors/exceptions, try it somewhere before using Fabric. (Debian is part of system so have to use Debian and other system tools)