Garret Wilson Garret Wilson - 2 months ago 24
Python Question

Getting cx_Oracle with correct case using conda

I'm new to Python. I'm using the Anaconda 4.1.1 (Python 3.5.2) distribution on Ubuntu. I started working on a project that uses

. O could of course install
cx_Oracle
using
pip
.

pip install cx_Oracle


But everyone seems to be saying that Anaconda's
conda
is a much better package manager, virtual environment manager, and dependency manager that
pip
and
virtualenv
put together. I'd prefer to just use
conda
for managing everything.

So I made a
requirements.txt
file (some of my teammates will still be using
pip
and
virtualenv
) with the following line. (I want to support Python 3.5, so I need
cx_Oracle
5.2.1, the current latest.)

cx_Oracle==5.2.1


Then I tell
conda
to create a virtual environment
foobar
:

conda create -n foobar --file requirements.txt


This fails; unfortunately
cx_Oracle
5.2.1 is not yet in the Continuum conda repository (even though half the year has passed since it was released). However there are several channels (e.g.
mgckind
) purporting to supply version 5.2.1. There's just one problem: all the channels are supplying
cx_oracle
and not
cx_Oracle
(note the case difference). So this won't work:

conda create -n foobar -c mgckind --file requirements.txt


Even if I specify a channel as in the example above, and even though
requirements.txt
clearly says
cx_Oracle
,
conda
brings down
cx_oracle
with a lowercase
o
. Because Python module imports are apparently case sensitive, all my tests fail because they can't find
cx_Oracle
with an uppercase
O
.

Am I missing something simple here because I'm new to Python? Or is Anaconda really both behind the times and incompatible with
cx_Oracle
, meaning I'll have to use
pip install
and bring it down from PyPI?

If there is really a case difference, is this situation common on Conda vs PiPY? Is it a Conda policy to name things only in lowercase? How do others deal with the discrepancy?

Answer

The problem had nothing to do with the lowercase package name on Continuum's conda repository. In fact I was missing something. I had created a new virtual environment as I mentioned in the question:

conda create -n foobar --file requirements.txt

The requirements file contained cx_Oracle==5.2.1, which I also mentioned. But what I did not mention is that I then tested the program using nosetests, and the requirements.txt file did not include nose! This means that the unit tests were being run by the default Anaconda installation of nose, which had no knowledge of cx_Oracle, which was not installed into the main Anaconda installation. (The virtual environment, because of dependency issues, had pulled down Python 3.4, while the Anaconda installation was using Python 3.5.)

In any case, the issue was that I inadvertently was using nose from the default installation of Anaconda, not from my virtual environment. The cx_oracle installed into my virtual environment, as kalefranz pointed out, will requires import cx_Oracle regardless of the case of its package name.

As soon as I installed nose into my virtual environment, running nosetests worked because it picked up the cx_oracle installation.

In summary the following seems to be the package/module case situation in the Python world:

  • Python module imports are case-sensitive.
  • Package names are case-insensitive.
  • The new best-practices approach is to use all lowercase in package names.
  • The PyPI repository retains case; the Continuum conda repository converts package names to lowercase.
  • Regardless of whether one pulls a package from PyPI or Continuum conda, and regardless of which package case is used to retrieve them, the module name and its corresponding import statement in the code should retain the official case used by the library.
Comments