The awk script that was processing modulefinder output to produce .d
files was not working because it was using \> to match a word ending,
but that is only supported in GNU awk:

https://www.math.utah.edu/docs/info/gawk_5.html#SEC29

Switched that for a more portable equivalent.

make install was broken since we moved to pythonparser because it was
not being copied into the install dir. Rather than just copying it into
the PYTHONPATH alongside grumpy, I thought it better to embed it within
the grumpy package so that it won't conflict with an installed
pythonparser.

This addresses: https://github.com/google/grumpy/issues/288

Previously importing logic was spread across two classes: Path which
looked for files in a list of directories and ImportVisitor which
processed import nodes and used a Path to resolve modules. That became
cumbersome when attempting to support relative imports because now two
modes of module resolution were necessary and a "level" param carried
through the calls.

This change collapses the Path and ImportVisitor functionality into a
single Importer class that processes import nodes and resolves to
modules directly. This class is stateless which makes it easier to test
and work with. It will also make it easier to implement relative imports
since the node processing and module resolution are integrated.

This test is causing too many Travis failures. Will re-enable when #282 is addressed.

This test is causing too many Travis failures. Will re-enable when https://github.com/google/grumpy/issues/282 is addressed.

In bc04caf4 I moved a bunch of tests into imputil_test.py but I failed to
add a __main__ check so the tests were never run. This change remedies
that and fixes the tests that were broken the whole time.

genmake looks in the src/__python__ subdir of a dir specified on the
command line and generates a makefile that describes how to build Go
packages from the .py sources.

The project Makefile now uses genmake to generate targets for the
stdlib.

Modules being imported are now detected at compile time. So it's
possible to determine whether "from x import y" is importing module y or
a member y of module x. This change uses this capability to choose
whether to import a module or a member.

This fixes https://github.com/google/grumpy/issues/99

Previously, grumpc assumed that all imports were valid Python modules.
So there was no way to distinguish between, for example, importing
a module within a package, or a package member of the same name.

This change makes it so that during code generation, Python source files
corresponding to the modules being imported exist on the GOPATH. If no
such Python source file exists, then an ImportError is raised.

Additionally, this change fixes an issue where imports within packages
or within modules within packages were not first checking for the named
import within the package directory. Now, package-relative imports work
as expected.

Import logic is currently embedded in the StatementVisitor class which
makes it difficult to reuse. This change factors that logic out into an
ImportVisitor class in util.py. The newly exposed logic can now be used
by other tools.

Python code compiled by grumpc will be staged in GOPATH/__python__ so
that modules can be detected at compile time.

Previously add_import(), add_native_import() and intern() were Block
methods that delegated to the root ModuleBlock internally. Now that the
ModuleBlock is accessible from any Block via the root attr, move those
methods to ModuleBlock.