edit-here directory shouldn't contain build files

[Nicholas Skaggs]

Ideally our edit-here directory will stay clean so it can be edited easily. Once you've built the project it contains other build-time files that if edited will simply be re-generated. To avoid this confusion, let's build in a better place.

Depending on the changes the tests also probably make sense somewhere else.

[Daniel Holbach (dholbach)]

Current structure:

├── app ← Everything related to the devices app.
│   └── www ← The viewable content of the app.
├── edit-here
│   ├── content
│   │   └── pages ← Here is the place to edit the content.
│   ├── po ← Translations.
│   ├── tests ← Code for automated testing goes here.
│  └── themes ← Themes files, both templates and css/js.
│      ├── phone ← Phone/device app theme.
│      └── web ← Online build (.ubuntu.com) theme.
└── web ← The viewable content of of the online build.

[Daniel Holbach (dholbach)]

I don't know if the below is actually possible, but to me it'd look quite clean...

.
├── build
│   ├── app
│   │   └── www
│   └── web
├── content
│   ├── images
│   └── pages
├── debian
├── po
├── themes
│   ├── phone
│   └── web
└── utils
    └── tests

What do you think?

[Nicholas Skaggs (nskaggs)]

Seems to make a bit more sense like this? Tests should probably be top-level, and I'm not sure why app was buried. But yes this is good.

 |──── app
├── build
│ │── www
│ └── web
├── content
│ ├── images
│ └── pages
├── debian
├── po
├── themes
│ ├── phone
│ └── web
└── tests

[Daniel Holbach (dholbach)]

'tests' are going to be relative to 'utils', where I'd let all the python code live. Or where would you put that kind of stuff?

'app/www' can't be broken up. It'll be what's shipped in the click app, that's why I thought I'd put it into build/.

[Daniel Holbach (dholbach)]

Theoretically we could let the python code live in the top-level directory...

[Nicholas Skaggs (nskaggs)]

Daniel, ack then the build directory makes sense. I do know what is in the app folder has a couple files you may edit (manifest, svg), but sure not critical I guess. I was hoping to be able to nuke the build folder with no ramifications. Ideally, nothing in there should be part of bzr.

Anyways, you can bury tests if you'd like, but I'm not sure what else you plan to go into utils.

[Daniel Holbach (dholbach)]

Right, theoretically we could put the app files into ./app/ and then move the ./app/www/ bits from somewhere else before build the click file.

./build/ would be around or not, it could be safely deleted and wouldn't be part of the branch. Would you prefer to let builds happen in /tmp/ somewhere, so it's completely invisible? (Nuking sounds a bit like that.) That might make the problem a bit harder all in all.

I'll have a look at what we can do in terms of tests and stuff. They might well live in the top-level directory. Maybe ./utils/ could hold all the ./generate* scripts, our q-and-a markdown extension, and maybe we'll break up translations.py into several distinct pieces at some stage.

[Nicholas Skaggs (nskaggs)]

Daniel, my preference for a build folder is always for it to be entirely generated. I prefer in-folder builds (as opposed to some other folder hidden somewhere like /tmp), but nonetheless the folder should all be generated and not have any files I care about in it. For that reason I can completely delete the folder and regenerate it at will. You could make an argument about build only having temporary files and the output (click package, html pages, etc) going somewhere else.

[Daniel Holbach (dholbach)]

Ok, I think that's sufficiently clear now. I'll start work on this once 0.1 is out the door. :)

[David Planella (dpm)]

Just a couple of additional notes:

It'd be great to be consistent with the output of app and web. That is, if we are building:

   ├── app
        └── www

Then we should probably do the same for the web build. That is:

   ├── web
        └── www

Also, for we're using 'app' for the build, but 'phone' to describe the theme. I think it might be a good idea to rename 'phone' to 'app' to be consistent there too.