Pyodbc works in "base" but not other envs

I have a newly installed anaconda environment on redhat 8. I installed microsoft ODBC driver, kerberos,etc. all without problem. Then I installed Anaconda.

The pyodbc seemed automatically installed on “base”. I then created a new environment:
“conda create -n tstdev python=3.9”
then install pyodbc:
“conda activate tstdev; conda install pyodbc”

Strange thing happens. I can use pyodbc in “base” env, but not the other env.

(base) [admsagz@srvaz01c01-jobd ~]$ conda activate base
(base) [admsagz@srvaz01c01-jobd ~]$ python
[(154, )] **=> pyodbc works in base **

(base) [admsagz@srvaz01c01-jobd ~]$ conda activate tstdev
(tstdev) [admsagz@srvaz01c01-jobd ~]$ python
Traceback (most recent call last):
File “/home/”, line 13, in
conn = pyodbc.connect(‘Driver={ODBC Driver 17 for SQL Server};;Database=DAI_NLP_DEV;Trusted_Connection=yes;Mars_Connection=yes’)
pyodbc.Error: (‘01000’, “[01000] [unixODBC][Driver Manager]Can’t open lib ‘/opt/microsoft/msodbcsql17/lib64/’ : file not found (0) (SQLDriverConnect)”)

The “missing” file exists and accessible, otherwise the pyodbc on base would not have worked.

Would anyone provide some clue? Thanks in advance.



More information. The behavior reproduces if use “isql” came with anaconda:

(base) [admsagz@srvaz01c01-jobd ~]$ which isql
(base) [admsagz@srvaz01c01-jobd ~]$ isql -v -k ‘Driver={ODBC Driver 17 for SQL Server};;Database=DAI_NLP_DEV;Trusted_Connection=yes;Mars_Connection=yes’
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
SQL> quit
(base) [admsagz@srvaz01c01-jobd ~]$ conda activate tstdev
(tstdev) [admsagz@srvaz01c01-jobd ~]$ which isql
(tstdev) [admsagz@srvaz01c01-jobd ~]$ isql -v -k ‘Driver={ODBC Driver 17 for SQL Server};;Database=DAI_NLP_DEV;Trusted_Connection=yes;Mars_Connection=yes’
[01000][unixODBC][Driver Manager]Can’t open lib ‘/opt/microsoft/msodbcsql17/lib64/’ : file not found
[ISQL]ERROR: Could not SQLDriverConnect
(tstdev) [admsagz@srvaz01c01-jobd ~]$

Here are ldd info for both isql:

(tstdev) [admsagz@srvaz01c01-jobd ~]$ ldd /apps/conda/anaconda3/envs/tstdev/bin/isql (0x00007ffc971f7000) => /apps/conda/anaconda3/envs/tstdev/bin/…/lib/ (0x00007fbe377df000) => /apps/conda/anaconda3/envs/tstdev/bin/…/lib/ (0x00007fbe377a3000) => /lib64/ (0x00007fbe3740e000) => /lib64/ (0x00007fbe37049000) => /lib64/ (0x00007fbe36e45000) => /apps/conda/anaconda3/envs/tstdev/bin/…/lib/./ (0x00007fbe37757000)
/lib64/ (0x00007fbe3762e000)

(base) [admsagz@srvaz01c01-jobd ~]$ ldd /apps/conda/anaconda3/bin/isql (0x00007ffc38bea000) => /apps/conda/anaconda3/bin/…/lib/ (0x00007fbac711e000) => /apps/conda/anaconda3/bin/…/lib/ (0x00007fbac70e2000) => /lib64/ (0x00007fbac6d4d000) => /lib64/ (0x00007fbac6988000) => /lib64/ (0x00007fbac6784000) => /apps/conda/anaconda3/bin/…/lib/./ (0x00007fbac7096000)
/lib64/ (0x00007fbac6f6d000)

(base) [admsagz@srvaz01c01-jobd ~]$ conda info

 active environment : base
active env location : /apps/conda/anaconda3
        shell level : 1
   user config file : /home/admsagz/.condarc

populated config files :
conda version : 4.10.3
conda-build version : 3.21.5
python version :
virtual packages : __linux=4.18.0=0
base environment : /apps/conda/anaconda3 (read only)
conda av data dir : /apps/conda/anaconda3/etc/conda
conda av metadata url : None

      package cache : /apps/conda/anaconda3/pkgs
   envs directories : /home/admsagz/.conda/envs
           platform : linux-64
         user-agent : conda/4.10.3 requests/2.26.0 CPython/3.9.7 Linux/4.18.0-305.25.1.el8_4.x86_64 rhel/8.4 glibc/2.28
            UID:GID : 756484642:756400513
         netrc file : None
       offline mode : False

(base) [admsagz@srvaz01c01-jobd ~]$ conda env list

conda environments:

base * /apps/conda/anaconda3
tstdev /apps/conda/anaconda3/envs/tstdev

Hi Kevin,

I would assume conda activate de-configured an environment variable somewhere. If you use the env command from within and without the activated environment, would you be able to determine which one it is?

Maybe these commands could help?

  • $ conda activate base
  • $ env > before
  • $ conda activate tstdev
  • $ env > after
  • $ diff before after

Hi Matt,

Thanks a lot for the reply. It seemed the differences were minimal:

(tstdev) [admsagz@srvaz01c01-jobd ~]$ diff before after
< CONDA_PREFIX=/apps/conda/anaconda3
> CONDA_PREFIX=/apps/conda/anaconda3/envs/tstdev
< CONDA_PREFIX_3=/apps/conda/anaconda3/envs/tstdev
< PATH=/apps/conda/anaconda3/bin:/apps/conda/anaconda3/condabin:/home/
> PATH=/apps/conda/anaconda3/envs/tstdev/bin:/apps/conda/anaconda3/condabin:/home/admsagz/.local/bin:/home/admsagz/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/mssql-tools/bin:/apps/conda/anaconda3/bin

Another finding, the pyodbc worked when I created a new environment which cloned the “base”. It sounded like there were some pyodbc dependencies issue given the “base” had lots more packages installed than python3.9 + pyodbc. However, cloning is not a sufficient option for us because it would limit the python version to the base version.

conda create --name mybase --clone base

Doesn’t look like it’s environment variables to me then.

That clone thing is weird though. Sounds like maybe there are some packages installed into (base) that aren’t getting captured as dependencies.

Next step I’d try is to compare the output of conda list within the two environments to see if there’s anything different.

I’ve asked some others to see if they have any ideas. I’ll report back.

1 Like

I’d like to report back the findings. The missing dependency was krb5 in our case. One would expect python to use operating system’s krb5 if it’s not included in conda but it was not the case.