views:

47

answers:

2

So we're writing a full-text search framework MongoDb. MongoDB is pretty much javascript-native, so we wrote the javascript library first, and it works.

Now I'm trying to write a python framework for it, which will be partially in python, but partially use those same stored javascript functions - the javascript functions are an intrinsic part of the library. On the other hand, the javascript framework does not depend on python. since they are pretty intertwined it seems like it's worthwhile keeping them in the same repository.

I'm trying to work out a way of structuring the whole project to give the javascript and python frameworks equal status (maybe a ruby driver or whatever in the future?), but still allow the python library to install nicely.

Currently it looks like this: (simplified a little)

javascript/jstest/test1.js
javascript/mongo-fulltext/search.js
javascript/mongo-fulltext/util.js
python/docs/indext.rst
python/tests/search_test.py
python/tests/__init__.py
python/mongofulltextsearch/__init__.py
python/mongofulltextsearch/mongo_search.py
python/mongofulltextsearch/util.py
python/setup.py

I've skipped out a few files for simplicity, but you get the general idea; it' a pretty much standard python project... except that it depends critcally ona whole bunch of javascript which is stored in a sibling directory tree.

What's the preferred setup for dealing with this kind of thing when it comes to setuptools? I can work out how to use package_data etc to install data files that live inside my python project as per the setuptools docs.

The problem is if i want to use setuptools to install stuff, including the javascript files from outside the python code tree, and then also access them in a consistent way when I'm developing the python code and when it is easy_installed to someone's site.

Is that supported behaviour for setuptools? Should i be using paver or distutils2 or Distribute or something? (basic distutils is not an option; the whole reason I'm doing this is to enable requirements tracking) How should i be reading the contents of those files into python scripts?

A: 

Read my answer here for a basic intro to setting up a dev environment.

Marcelo Cantos
Hi Marcelos - To clarify, I'm already using virtualenv - in fact, Doug Hellman's execllent virtualenvewrapper: http://www.doughellmann.com/projects/virtualenvwrapper/. And I have a working setup.py install script as far as python modules and packages goes. However, getting that javascript rolled into the python sdist and ultimately deployed is what my question is about, that is, how to use setuptools or whatever to get the parallel hierarchy of javascript files that lives adjacent to the python project installed in the python project sdist. Any idas on that point?
dan mackinlay
+2  A: 

The short answer is that none of the Python distribution tools is going to do what you want, the exact way you want it. Even if you use distutils' data_files feature, you're still going to have to have your javascript files copied into your Python project directory (i.e., somewhere under the same directory as your setup.py.)

Given that, you might as well just copy the .js files to your package (i.e. alongside mongofulltextsearch/init.py) as part of your build process, and use package_data or include_package_data=True.

(Or alternatively, you could possibly use symlinks, externals, or some such, if your revision control system supports those. I believe that when building source distributions, the Python distribution tools convert symlinks to real files. At least, you could give that a try.)

pjeby
OK, that's worthwhile knowing. For the public record, I've hacked something together using symlinks on the basis of this, and it does indeed work (that is - they do get converted to real files by setuptools' sdist). It's hardly a basis for a robust cross-language solution ATM and isn't cross platform either (sorry, windows!), so I think I'll ditch cross-platform support and go for your other suggestion of a smarter build-script (or possibly, since this is a git project, a git-external) and one repository for each language. Thanks!
dan mackinlay
"ditch", that is, not "cross platform support", but multiple *language* support in a single repository. Sorry, late night muzzy thinking there.While I'm posting updates, if you are the P. Eby that I think you are - thanks for both the tips, and the work on setuptools itself!
dan mackinlay