Tuesday, May 12, 2009

managing installation requirements by Python version

I always feel guilty using this blog as my LazyWeb, but it works really well, so here we go again...

I'm trying out Oracle Enterprise Linux 5 - basically a clone of RHEL - and trying to get sqlpython installed on it. OEL5 comes with Python 2.4; sqlpython 1.6.5.1 needs Python 2.5. I could take out the 2.5 dependency in sqlpython, but it uses pyparsing. Pyparsing dropped 2.4 compatibility as of 1.5.2.

[EDIT: It turns out that pyparsing 1.5.2 still works on Python 2.4. It emits a scary error message, during easy_install under Python 2.4 -
except ParseException as err:
^
SyntaxError: invalid syntax

but it installs successfully nonetheless. Thanks to Paul McGuire to pointing that out. So my job in this case is simply to release a 2.4-compatible sqlpython 1.6.5.2.]

I could change install_requires=['pyparsing>=1.5.1'] to install_requires=['pyparsing==1.5.1'] in setup.py, but that locks everybody into an obsolete pyparsing whether they need it or not.

I'd like to install_requires=(['pyparsing>=1.5.1'] if python.version >= '2.5' else ['pyparsing==1.5.1']), but that's absolutely imaginary syntax.

Obviously, I could just download a newer Python and install it on my machine, but I'm trying to make sqlpython usable for DBAs who don't have that kind of authority, or who fear to muck around with their environment that way.

I wonder what the smart people do in situations like this?

7 comments:

Mike Pirnat said...

I'm on the verge of suggesting rolling a separate "pre-2.5-compat" release of sqlpython, except that it feels gross and inelegant to me.

:-[

Bryan said...

You could have an OEL5.patch that changes install_requires>= to install_requires==. I'd say a pretty good percentage of debian packages have this sort of workaround in the debian directory. The whole point of RHEL based linuxes is that they don't change very much so the ==1.5.1 is probably the desired state anyway. Is 1.5.2 a security update?

Paul McGuire said...

What?! I did not abandon 2.4 compatibility in pyparsing 1.5.2 on purpose! What has stopped working? Are you getting syntax errors? If so, please post them to the pyparsing wiki or support tracker on SF.

Thanks,
-- Paul McGuire
(can't remember my )$@(#!@@!! Blogger password!)

Catherine said...

Hi, Paul! I guess I assumed I was the only one who introduces 2.4-breaking features by accident.

I filed my easy_install-2.4 output as the bug at

https://sourceforge.net/tracker/?func=detail&aid=2791004&group_id=97203&atid=617311

jafo said...

Welcome to my world... Supporting enterprise linuxes with Python can be a challenge. Sounds like you've got the right response from Paul though.

Sean

ptmcg said...

Hmm, although you got some syntax errors, I'm not sure this is a total failure. Pyparsing 1.5.2 ships with pyparsing.py (for Python 2.x) and pyparsing_py3.py (for Python 3.x). I don't know how to design my egg for adaptable installation. But if your pyparsing.py file installed on Py2.4, then that should be adequate for successful use of the module. (Python 3 users will experience the opposite case - they will get syntax errors on pyparsing.py, but pyparsing_py3.py should install ok.)

-- Paul

Merwok said...

Hello

> that's absolutely imaginary syntax.
Is there a joke I don’t get, or do you refer to it not working with Pythons < 2.5?

Anyway, you could still define the install_requires list within an if block.

Cheers