- Better-described questions. "Are you creating a Zope 2 Product?" is very unclear and unhelpful in describing what it does.
- A "verbose help" mode. We'll add the ability to have longer descriptions that can also appear in this new mode.
Personal preferences for ZopeSkel (like a
$HOME/.zopeskel file, where common answers for things like author-name, copyright, etc., could come from.
- Answers to questions that can prompt/hide other questions. In the Archetypes field-building local command ("atschema"), we'd like to ask questions like "What types can be added inside of this?" *only* if the item is folderish (it makes no sense otherwise).
- Ask fewer questions. Questions like "tell us your namespace and package names" could be answered by taking the egg name and splitting it on the dot. (There may be Core Developer users who would prefer to name the egg 'Foozle' and have the actual namespace/package be 'joelburton.foozle', but we don't think this is the common case or a best practice that needs to be supported--this egg would be named 'joelburton.foozle'. (This problem, of the egg name vs namespace/package names is one of the most confusing, and most incorrectly-answered things, in Joel's experience).
- In verbose-help mode, we should provide a short-but-helpful note at the end about what paster/ZopeSkel did and what next steps might be (like we do now for localcommands).
- Make the list of exact file changes (& number of bytes added, etc.) not appear by default--this is really a logging issue for recipe debuggers, and seeing this is too much information for new users, and may drown out the more helpful "what to do now messages".
- Produce documentation on good recipe-writing and how to have add-on-recipes, so that people who want to have their company's "our type of Plone product" recipe, can more easily do so.
- Potentially: rename this. "ZopeSkel" invites all Zope products to add code to one egg, making it hard for new users to get only the Plone-specific, easy-to-use eggs. This might be better a series of smaller eggs, with things like silva and non-Plone-zope kept elsewhere. Plus, this would insulate people who might depend on absolute 100% backwards-compatility with an unchanged "zopeskel". We are undecided on this point.
We might end up with things like:
plone.pastescript <= recipes (aka, the stuff most people use plone.pastescript.coredev <= recipes for making core-plone plone.pastescript.experimental <= experimental recipes? zope2.pastescript <= non-Plone zope templates silva.pastescript <= silva stuff plone.pastescript.buildouts <= recipes to get buildouts ZopeSkel <= for backwards compat, depends on all above
(These are total straw names)
Goals proposed by Godefroid Chapelle:
- ZopeSkel packages should by default hold a buildout (if really needed, user could be asked if she wants an enclosed buildout). That buildout would have a test part that uses zc.zope2testrunner to run all package tests. This implies the code should be moved to a src subdirectory to avoid confusing buildout (see http://rpatterson.net/blog/running-tests-in-egg-buildouts).
- The default tests should be refactored. Should we use collective.zopetestcaselayer because it eases writing tests setup a lot?