Re: More flexible create-module.py and contrib/wscript (issue 343030043 by pdbj@mac.com)

[tomh...@gmail.com]

On 2018/08/06 23:13:49, Peter Barnes wrote:
> @Tom: I don't understand your last comment re: project grouping and
project
> structure...

My comment was about whether we want to encourage or allow that modules
can be standalone or part of a 'project' (that is, whether we want to
encourage a uniform usage of a project structure; e.g.

utils/create-project.py contrib/projectname moduleNameA moduleNameB
moduleNameC

would yield

contrib/
projectname/
moduleNameA
moduleNameB
moduleNameC

and do not continue with the standalone 'create-module.py'

However, looking at this issue again today, I think your current
proposal is fine; if someone wants to create the 'project/' and 'data'
structure themselves, and add modules to it as they go, they can call
your (revised) create-module.py after creating the project structure
that they want, or if they instead just want something simple, they can
use create-module.py the same way as before.

https://codereview.appspot.com/343030043/

[pd...@mac.com]

On 2018/08/12 22:48:11, Tom Henderson wrote:

> utils/create-project.py contrib/projectname moduleNameA moduleNameB
moduleNameC

> would yield

> contrib/
> projectname/
> moduleNameA
> moduleNameB
> moduleNameC

> and do not continue with the standalone 'create-module.py'

Ahh, now I get it. An alternative to supporting create-project.py *and*
create-module.py might be:

utils/create-module.py --project projectname moduleA moduleB moduleC

One script to rule them all.

Do projects only make sense in contrib (as I've implicitly assumed in
the command above)? Or should we the script be agnostic?

https://codereview.appspot.com/343030043/