Add web frontend as an option of zpm new, don't generate it on zpm bundle

[larsbutler]

zpm new simply creates a zapp config file (zapp.yml). Before deploying, zpm bundle creates web frontend artifacts (index.html. style.css, zebra.js, etc.) from templates and packs them into the .zapp archive.

The problem is, this makes is difficult to customize the web frontend. If a custom index.html file is created, it's overwritten by the rendered template created at bundle time.

Example output of zpm bundle:

~/myapp $ zpm bundle
adding myapp.json
adding /home/lars/myapp/foo.py
adding /home/lars/myapp/index.html
adding /home/lars/myapp/zapp.yaml
adding index.html
adding style.css
adding zerocloud.js
created myapp.zapp

The custom index.html file is being overwritten.

I propose the following changes:

1. Don't override custom UI artifacts, if they exist in the project root. (TODO: Maybe figure out some better structure for this, rather than just dump everything into the root of the project dir.)
2. Add a --with-ui flag to zpm new to generate the UI template files (index.html, zerocloud.js, style.css), in addition to the zapp.yaml. Similar to the zapp.yaml, the UI templates can be customized.
3. zpm bundle: don't automatically create web UI files for every application. There are many cases where applications would be execute remotely (command-line, etc.) and will have no need for a UI.

Edit: Renamed zebra.js to zerocloud.js

[mgeisler]

When you say index.html is being overwritten, do you mean overwritten in the project directory? That is not supposed to happen, infact, I don't think zpm bundle writes anything but the foo.zapp file to the host filesystem.

[larsbutler]

When you say index.html is being overwritten, do you mean overwritten in the project directory? That is not supposed to happen, infact, I don't think zpm bundle writes anything but the foo.zapp file to the host filesystem.

No, not the project directory; the zapp itself.

I think my confusion was in the use of ui section. I'm wondering if we can just remove this section and just specify UI artifacts (explicitly) in bundling. Then, using zpm new --with-ui as I've described above, generate UI templates once. I think this is more explicit. It also means that it's possible to write applications without a web UI. (If I just want to make a command-line application, it's annoying to have web UI artifacts by default in my zapp.)

So to recap: zpm new --with-ui would

1. Generate zapp.yaml, index.html, style.css, and zerocloud.js
2. Populate the bundling list in zapp.yaml to include the web UI files by default

This would easily allow the developer to generate UI defaults (but only if needed) and then customize them.

[mgeisler]

The difference between the bundling and ui sections is essentially this:

• Files in bundling are just left in the the zapp and can only be accessed when the zapp is mounted as an image
• Files in ui are unpacked from the zapp when zpm deploy is run
• Files in ui can be templates (when Do not expand all UI files as Jinja2 templates #132 is merged)

I think we need this functionality, we want to specify two lists: the files to include in the zapp and the (subset) of these files that we want to see unpacked when it is deployed. Having the bundling and ui lists seems like a good way to do that. The name ui is not the best, though, so maybe we should rename it to unpacked or similar.

[mgeisler]

What you're suggesting seems to require that the user will add the auto-generated zerocloud.js file to their version control system. If possible, I would prefer having that auto-generated and inserted into the zapp at zpm bundle time. Simply to avoid people getting stuck with an old version of zerocloud.js (how will they update it in the future?).

[larsbutler]

@mgeisler

The difference between the bundling and ui sections is essentially this:

• Files in bundling are just left in the the zapp and can only be accessed when the zapp is mounted as an image
• Files in ui are unpacked from the zapp when zpm deploy is run

Okay, in that case it makes sense to keep them as separate sections. So that's fine. But I still think file inclusion should be explicit. For instance, if I remove the ui section from my zapp.yaml, I don't want UI files to still be implicitly included (especially if I have no control over it).

• Files in ui can be templates (when Do not expand all UI files as Jinja2 templates #132 is merged)

I think we need this functionality, we want to specify two lists: the files to include in the zapp and the (subset) of these files that we want to see unpacked when it is deployed. Having the bundling and ui lists seems like a good way to do that. The name ui is not the best, though, so maybe we should rename it to unpacked or similar.

[larsbutler]

What you're suggesting seems to require that the user will add the auto-generated zerocloud.js file to their version control system. If possible, I would prefer having that auto-generated and inserted into the zapp at zpm bundle time. Simply to avoid people getting stuck with an old version of zerocloud.js (how will they update it in the future?).

Yes, that it what I'm suggesting. But there's more to it than that:

If we auto-generate zerocloud.js, forcing users to always use the latest version, then we need to make promises about the stability of that code. Instead, I think it would be cleaner to generate zerocloud.js only if the user wants it when starting a new project. If they want to upgrade, they do it when they are ready (just like any other javascript library), and not when we force them to. We can post the various versions somewhere so they can choose when to upgrade and to which version.

Explicit is better than implicit.

[mgeisler]

I think my suggestion in #141 would help: zpm new could generate a ui section with

ui:
- "<index.html>"
- "<style.css>"
- "<zerocloud.js>"

The user can then remove things from this list as desired or leave the section out completely. With no section, no UI files are added.

[mgeisler]

If we auto-generate zerocloud.js, forcing users to always use the latest version, then we need to make promises about the stability of that code.

Yes, and I believe we should be making such a promise at some point.

We can do all sorts of things to let the user lock the version: we could name the template zerocloud-1.js or we could say that people should include the file themselves (like today).

[larsbutler]

The user can then remove things from this list as desired or leave the section out completely. With no section, no UI files are added.

So what if the user wants to customize the generated default index.html? What does that workflow look like?

[larsbutler]

The other question is: How do I create a zapp without a UI? Most of the zapps I create don't have a UI, so it's kind of annoying to always have one when I don't need it. There doesn't seem to be a way to omit it.

[mgeisler]

Lars Butler [email protected] writes:

The other question is: How do I create a zapp without a UI? Most of
the zapps I create don't have a UI, so it's kind of annoying to always
have one when I don't need it. There doesn't seem to be a way to omit
it.

I think we talked about this: you specify an empty list for the ui key.
Then no files will be unpacked when you "zpm deploy".

[larsbutler]

Is that something we should implement, or is that how things are supposed to work currently? Because that doesn't work. A UI is always included no matter what.

[larsbutler]

That is, it's always included in the .zapp file.

[mgeisler]

That is, it's always included in the .zapp file.

I'm sorry, I was under the impression that explicitly setting the UI
files to an empty list would prevent the default UI files from being
added. I now see that the code doesn't care whether the list is empty or
not specified at all.