Getting cx_Oracle with correct case using conda

Question

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 cx_Oracle. 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 1

The conda package name does not influence how your import the code in python. Looking at the linux-64 package here for example, while the package name is cx_oracle to conform to conda ecosystem standards, in python you must import that package with import cx_Oracle. There are many examples of python packages on PyPI where the package name is different than how the package is imported in python code. Just one of those python quirks I guess.

Answer 2

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.