Install PYODBC on Centos / RHEL

https://medium.com/analytics-vidhya/install-pyodbc-on-centos-rhel-ae5062830a2b

Comments

[Nathan Standiford]

As a regular user of CentOS and RHEL, I've found it convenient to work with software collections and virtualenv. This way I am able to target a specific version of Python that may not yet be released to the mainstream repositories. Also, I can keep my python dependencies clean for use in other projects.

Here's how to do it with the Software Collections on CentOS and RHEL. You may need to replace yum with dnf depending on your distribution.

On your CentOS system, install the software collections repo.

sudo yum group install "Development Tools"
sudo yum install centos-release-scl

Alternately, a RHEL system would need the following:

sudo yum install @development
sudo subscription-manager repos \
--enable rhel-7-<workstation-or-server>-optional-rpms \
--enable rhel-<workstation-or-server>-rhscl-7-rpms

Once you have scl installed, install the latest version of python3 and unixODBC-devel:

$ sudo yum install rh-python38 unixODBC-devel

Now, let's create a virtual environment. This should be included as part of python3.

$ scl enable rh-python38 bash
$ python3.8 -m venv myproject

Now, instead of using scl, we can now use source to enable our python3.8 environment:

$ source ./myproject/bin/activate

As you can see, you are now in a virtual environment!

(myproject) $ python -V
Python 3.8...

Now, update pip, wheel, distribute, and setuptools:

(myproject) $ pip install --upgrade pip
....
(myproject) $ pip install --upgrade wheel setuptools distribute

Now that we are updated, we should be able to install pyodbc:

(myproject) $ pip install --upgrade pyodbc

Test it out if it works:

>>> import pyodbc

Now, if you ever need to share your project dependencies with another human being, you can do so like the following:

(myproject) $ pip freeze > requirements.txt

And then, if you did everything right, you should have something like the following:

$ cat requirements.txt
pyodbc==4.0.30

I want to make a personal note that it is VERY important that every team member consumes the same library version. That said, it is also very important to add testing behind any code you are doing so that you can catch any errors that may occur when you do a package upgrade for whatever reason. If you are planning on releasing this to production, you will want to install specific versions of the library components. This is why a good CI/CD pipeline would help find issues early on whenever a version has changed. This can be done as a precommit hook, during a pull request, and/or during a merge. The needs depend largely on your organization. However, investing on good devops early on will reduce technical debt and dramatically decrease cost of the project.

[Ganesh Chandrasekaran]

Very true and I agree with you.

The steps I had mentioned was generic not specific to how they want to use in their environment.