Run script

[dusty-phillips]

Merge (rewrite) the generate_library.py into pyjs.py

This commit also moves the library into the pyjaco package to ease distribution via setup.py.

The output of the new generate script is not quite identical to the output of the original. I passed it through vimdiff and found the following:

• all multi-line comments are stripped, not just the headers. This was an intentional change.
• there are some misalignments on the /* somefile.js */ headers in terms of blank lines surrounding it. This is cosmetic and doesn't matter
• the value of the /* somefile.js */ headers no longer includes the "library/" directory.

The second commit is a bug I discovered in testing. The parser was not able to error because there was no reference to the parser. Moving the parser to a global was a quick fix, there should probably a bit more object orientation in this script, eventually.

I am going to make a few further changes that will likely end up on this same pull request (unless you happen merge it ahead of me):

• Allow -b generate to be passed with zero input files. In this case, the py-builtins.gs will be generated to standard out, or to the output filename or directory if specified with -o
• Allow multiple input filenames to be passed on the command line. Currently exactly one input filename can be specified, but it can be a directory containing multiple files. There should be no reason that multiple arguments can't be included instead/too.

[dusty-phillips]

I forgot to mention, this commit addresses Issue #7.

[chrivers]

Thanks again for great contributions! :)

I'm a bit apprehensive about moving everything into pyjaco/jslib, however. As it is now, pyjaco/ is the python module root dir, and library/ is a data dir containing all the javascript files.

Having javascript files in the python module dir irks me. I think we have to settle for another location. What can we do with regards to pypi? Can we name a data dir that will be copied somewhere? How does it work?

By the way, I agree completely that the debian package should simply use the pypi infrastructure. The other python-* debian packages already do this, I just created a quick-and-dirty debian package because we needed it.

Other than the data placement issues, this looks awesome. I can't wait to merge it.

[dusty-phillips]

I'm not a distutils guru by any means, but my research suggests the
following:

While distutils does supply a data_files option, it does not seem
possible to know without a doubt where those data_files have been
installed to. It is operating system, virtualenv, buildout, and os
dependent, and changes whether or not you use an egg.

The advantages of pkg_data are summarized here:
http://www.no-ack.org/2010/09/including-data-files-into-python.html

As far as I can tell, if the python code needs to access the file,
pkg_data should be used. See here:

http://docs.python.org/distutils/setupscript.html#installing-package-data

If you wish to keep the directories separate, we could have two separate
python packages. However, since pyjaco essentially depends upon the
presence of the *.js files, I believe they should be distributed with
that package.

Additionally, I found out that I should have been using pkg_resources to
load the files so they can be retrieved from an egg, amoung other
things; I will make this change once we've settled how to distribute the
library files.

On 06/01/12 12:37 PM, Christian Iversen wrote:

Thanks again for great contributions! :)

I'm a bit apprehensive about moving everything into pyjaco/jslib,
however. As it is now, pyjaco/ is the python module root dir, and
library/ is a data dir containing all the javascript files.

Having javascript files in the python module dir irks me. I think we
have to settle for another location. What can we do with regards to
pypi? Can we name a data dir that will be copied somewhere? How does
it work?

By the way, I agree completely that the debian package should simply
use the pypi infrastructure. The other python-* debian packages
already do this, I just created a quick-and-dirty debian package
because we needed it.

Other than the data placement issues, this looks awesome. I can't
wait to merge it.

--- Reply to this email directly or view it on GitHub:
#10 (comment)

[dusty-phillips]

As per our discussion via jabber, I have rewritten this commit to put the files in pyjaco/stdlib instead of pyjaco/jslib, and have added a commit to load the files using pkg_resources instead of file, thus allowing the distribution to be shipped as a compressed egg.