zpm new --template <template>: Templates are now explicit. The default template was python-specifc anyway, and this change allows for extension. (The next template I plan to implement is one for zapps written in C.)
zapp.yaml files have a new optional directive: project_type. If none is specified, the default is assumed to be python. The project_type is the same as the --template chosen with zpm new.
Older zapp.yaml files with no project_type are assumed to be python projects. This may cause some headaches for a few users (who might be doing C), but shouldn't be a problem for most.
zapp.yaml files have a new optional directive: depends. depends is a list of 3rd party python package names. This is a convenience for zapp developers who want to include pure python libraries which are not in the python standard library. When zpm bundle is called, these depends are fetched (using pip) and cached in the .zapp directory (located in the working directory containing the zapp.yaml). Dependency fetching and caching are handled using tox. This is a bit quick-n-dirty, but it seems to work well enough for the moment. The advantages provided by tox could also enable new commands, like zpm test (similar to go test for the Go language).
zpm bundle --refresh-deps: Since python dependencies are locally cached (so time is not wasted fetching them every time zpm bundle is called), a user may want to refresh those dependencies, particularly when the depends section is updated.
Known issues:
For some third party python libraries, like BitVector, the tox/pip-based mechanism will encounter problems fetching the package. It will give an error about fetching externally, and will suggest to use pip install --allow-external BitVector BitVector to install this dependency. Some hacking of the tox.ini created by zpm new --template=python can work around this.
This patch add several new things:
zpm new --template <template>: Templates are now explicit. The default template was python-specifc anyway, and this change allows for extension. (The next template I plan to implement is one for zapps written in C.)zapp.yamlfiles have a new optional directive:project_type. If none is specified, the default is assumed to bepython. Theproject_typeis the same as the--templatechosen withzpm new.zapp.yamlfiles with noproject_typeare assumed to bepythonprojects. This may cause some headaches for a few users (who might be doing C), but shouldn't be a problem for most.zapp.yamlfiles have a new optional directive:depends.dependsis a list of 3rd party python package names. This is a convenience for zapp developers who want to include pure python libraries which are not in the python standard library. Whenzpm bundleis called, these depends are fetched (usingpip) and cached in the.zappdirectory (located in the working directory containing thezapp.yaml). Dependency fetching and caching are handled usingtox. This is a bit quick-n-dirty, but it seems to work well enough for the moment. The advantages provided bytoxcould also enable new commands, likezpm test(similar togo testfor the Go language).zpm bundle --refresh-deps: Since python dependencies are locally cached (so time is not wasted fetching them every timezpm bundleis called), a user may want to refresh those dependencies, particularly when thedependssection is updated.Known issues:
tox/pip-based mechanism will encounter problems fetching the package. It will give an error about fetching externally, and will suggest to usepip install --allow-external BitVector BitVectorto install this dependency. Some hacking of thetox.inicreated byzpm new --template=pythoncan work around this.