For example it doesn't remove spaces...

So if I add e.g. "Banner Slide" or "News Item" then my imports will look like this:

 from another.product.interfaces import IBanner Slide
 from another.product.interfaces import INews Item

Currently in the Dexterit schema the interface is referenced for the schema (see https://github.com/plone/bobtemplates.plone/blob/master/bobtemplates/plone_addon/src/%2Bpackage.namespace%2B/%2Bpackage.name%2B/profiles/default/types/%2Bpackage.dexterity_type_name%2B.xml.bob#L27)
To enhance TTW exchangeability and remove a potential error cause (if you add a supermodel and don't remove the schema interface Plone will still use the schema interface) it would be good to ship the template with a supermodel-xml prepared.

We are missing an includeDependencies in configure zcml:

<includeDependencies package="." />

Any test setup with a dependency that is not explicitly declared will fail.

cd src
../bin/mrbob -O my.addon bobtemplates:plone_addon
[answer questions]
cd ..
update buildout.cfg 
bin/buildout
$ bin/test -s my.addon --list-tests
Listing my.addon.testing.MyAddonLayer:IntegrationTesting tests:
test_browserlayer (my.addon.tests.test_setup.TestSetup)
test_product_installed (my.addon.tests.test_setup.TestSetup)
test_uninstall (my.addon.tests.test_setup.TestSetup)

As you can see the robot test in test_example.robot is missing, but I can't see why?

updates to buildout.cfg were the obvious 3 lines....

[sources]
+my.addon = fs my.addon
collective.behavior.banner = git https://github.com/collective/collective.behavior.banner.git

[buildout]
test-packages =

• my.addon[test]

eggs =
collective.behavior.banner

• my.addon

Having tests is considered best practice. People can just ignore them or nor run them if the choose to. Therefore I would remove this question in order to keep things simple.

Opinions?

If you specify "package.theme = False" in an ini file it will ask the question anyways. We should make sure that "False", "false", "0" all work (maybe even "no"/"No").

I see that we ask about which python version you want to use defaulting to 2.7.

Is there a need to keep 2.6 around? Specially as Plone 5.0 does only have jenkins jobs for 2.7 (so we are not checking any regression with 2.6) and that since 4.x we are already supporting officially 2.7?

Really stable linux distributions (read RedHat/CentOS) are the only ones still keeping us to really remove python 2.6 support? Although you can still install 2.7 on them easily...

Hi, I'm willing to do some work on this, but before I go to far, can I test opinion here?

I think it would be good to have uninstall profiles by default (at least when gs profiles are asked for).
This would help people create products that really cleanly uninstall.
And is especially useful as there are3 or 4 "hoops" to jump thru to get uninstall profiles working which folk won't bother with figuring out.
I also would plan to add a test that checks that installing & uninstalling a product leaves the same (number of):

• Skin layers
• Browser layers
• CSS files in registry
• JS files in registry

I guess this won't work in all cases, but it would be a good baseline to further enourage clean uninstalls, right?

Your thoughts?

It would be nice if the script would expose the package type options: Basic, Dexterity, Theme

This could significantly speed up the travis build time. 8 minutes per build is too much.

https://travis-ci.org/plone/bobtemplates.plone: "No builds for this repository"

Or is there a good reason to leave it out?

Once #46 is merged we have to add acceptance tests for the theme and run them on travis.

Do we really need to ask for a version? We are always creating the first version of a package. This means it is will always be 0.1 or 1.0a1. I would drop the question. Opinions?

Maybe we could also document steps how to upload the docs to readthedocs.

I just noticed that there's a part to install i18ndude but it is not listed on the parts to be installed...

Any reason for that?

So we can replace zopeskel here:

https://github.com/plone/documentation/blob/master/develop/addons/dexterity.rst

Related documentation issue: plone/documentation#193 (comment)

Question is: do we want to have dexterity/theme/etc as a separate bobtemplate or do we want to integrate it into the existing plone_addon template.

cc @svx

I've created a template viewout a sample view and now the package contains a view.pyc without a view.py

When I generate a dexterity add'on using bobtemplates.plone 1.0b1 the vanille buildout pulls in plone.app.event 2.X (for Plone 5) which breaks the buildout.

plone.app.event is pulled in by plone.app.contenttypes, and there I've lost which package in the current setup is pulling in p.a.contenttypes (if that's the cause).

Quick fix is adding pins for plone.app.event and other packages that plone.app.contenttypes needs that work for Plone 4, but p.a.event and it's dependers shouldn't be in here at all.

# for plone.app.contenttypes 1.1b5
plone.app.contenttypes = 1.1b5
plone.app.event = 1.1.5
icalendar = 3.9.0
plone.event = 1.1
plone.formwidget.datetime = 1.1
plone.formwidget.recurrence = 1.2.5

Currently the Dexterity pattern creates a content with
plone.dexterity.content.Item content class (see
https://github.com/plone/bobtemplates.plone/blob/master/bobtemplates/plone_addon/src/%2Bpackage.namespace%2B/%2Bpackage.name%2B/profiles/default/types/%2Bpackage.dexterity_type_name%2B.xml.bob#L23)
In 100% of my use cases I change this to a custom class living in the package itself. This could be part of the template.

This dependency is not necessary for basic or theme packages and without version pinning it leads to buildout problems.

With the default options bobtemplates.plone creates a setup.py with the following classifiers:

    # Get more from http://pypi.python.org/pypi?%3Aaction=list_classifiers
    classifiers=[
        "Environment :: Web Environment",
        "Framework :: Plone",
        "Framework :: Plone :: 4.3.4",
        "Programming Language :: Python",
        "Programming Language :: Python :: 2.7",
    ],

According to the cited list
4.3.4 is not valid but 4.3 is:

Framework :: Plone
Framework :: Plone :: 3.2
Framework :: Plone :: 3.3
Framework :: Plone :: 4.0
Framework :: Plone :: 4.1
Framework :: Plone :: 4.2
Framework :: Plone :: 4.3
Framework :: Plone :: 5.0

How to replicate this issue.

Create a new package using mr.bob, when asked select "Dexterity" then name the content type something like "Car Part".

After adding it to you buildout and relaunching Plone you'll get an error like this:

 SyntaxError: invalid syntax (interfaces.py, line 14)

You will see that interfaces.py contains a class with a space in it (ICar Part) in this case, which is not valid for Python.

Use the Plone 5-specific cfg's from https://github.com/collective/buildout.plonetest

travis.cfg.bob refers a createcoverage section, which is not defined.
.travis.yml.bob also include a bin/createcoverage call

Hello,

i always get this error:
Error: 'C:\Plone42\src\test.test' is not a valid packagename.

I assume its because of this check:
validate_packagename(configurator):

https://github.com/plone/bobtemplates.plone/blob/master/tests.py is a good start, but we are far away from testing every possible combination of questions.

We already have functional acceptance tests for the main package types (regular, nested, in the future: theme, dexterity), which are the most important tests in my opinion.

Nonetheless, I think we should aim for 100% test coverage (for just unit tests) as well. Acceptance test coverage should not count. First step would be to refactor tests.py to not rely on external question.ini files. It is also essential to keep things simple, otherwise we will not be able to reach 100% test coverage with reasonable effort.

Design Goals

• Simple is better than complex.
• Cover 80% of use cases, don’t become too complex.
• Provide a good starting point for development, not a swiss army knife for the entire development cycle.
• Code and tests should reflect the current coding best practice.
• Generated code should have 100% test coverage.

Concrete Decisions

• Do not use local commands. They significantly increase complexity and mr.bob has no support for them anyways. We tried this with ZopeSkel/Templer and it did not work out that well.
• Limit the overall number of questions to not confuse people too much. Having separate packages or providing commented out code sections might be a good alternative.
• Fix problems in Plone itself rather than providing workarounds in our templates. (see #27)
• Provide skeletons for the most important Plone package use cases, not for every possible scenario:
  • Add-on product (collective, plone, custom project, policy product)
  • Content Types (Dexterity, Archetypes?)
  • Theme

This is just a draft and open for discussion. Feel free to comment or propose additions. I would especially like to hear the opinion of @cewing and @smcmahon. If we can reach an agreement we can add those design goals to the docs.

While it is generally a good idea to have a buildout.d directory with multiple files for a deployment buildout, I don't think this makes any sense for a Plone add-on product. The buildout in an add-on product will always be quite simple and this has the potential to confuse people.

I plan to use bobtemplates.plone for a training and I would prefer if I wouldn't to have to explain the entire buildout.d structure.

I would propose to merge all buildout.d files into a single top-level buildout.cfg. We can always create a second template for a deployment buildout for instance, where a buildout.d directory would make sense. Opinions?

BTW: buildout.d/jenkins.cfg is really really outdated and should not be used at all.

otoh this might be a bug in plone.app.testing...

Currently it is:

plone.version.question = Plone version
plone.version.help = Which Plone version would you like to use?
plone.version.default = 4.3.4
plone.version.post_ask_question = bobtemplates.hooks:post_plone_version

This is fed into:
i) Pypi Trove classifers (even though 4.3.4 is invalid)
ii) plone.is_plone5 variable

What niggles me is that the implication that an addon IS plone 5 is incorrect, we should say supports plone 5 - and perhaps more importantly we should work the same out for plone 4.

I'd like to see the above question (& help) changed to something like "Target Plone version" & then follow up with:

 plone.support_version4.question = Support Plone 4?
 plone.support_version4.default = True
 plone.support_version4.pre_ask_question = bobtemplates.hooks:skip_support_qu_if_we_know

 plone.support_version5.question = Support Plone 5?
 plone.support_version5.default = True
 plone.support_version5.pre_ask_question = bobtemplates.hooks:skip_support_qu_if_we_know

(With a slightly shorter hook function name ;-) )

This would help make code tidier for Plone 5 if we knew the product wasn't planning to support Plone4

Any objections/thoughts?

A profile is usually what newbies want anyways, so let's get rid of that question to simplify things.

For some reason it does not show coverage results at https://coveralls.io/github/plone/bobtemplates.plone

Locales should be considered best practice. Even if they are not used. I would drop this question and always include a locales folder.

Opinions?

Does anybody really care about those keywords? We could just set it to "Plone Python" and people can always add their keywords later. I would like to get rid ot this question.

Opinions?

I've tried to recreate the readme at the end of the text:
and since this package is not released on pypi I used the git url trick for pip:

pip install git+https://github.com/collective/bobtemplates.plone.git

After this, I could create the template.
Further analysis of the log showed this helpful log message:

...
Installing collected packages: bobtemplates.plone
  Running setup.py install for bobtemplates.plone

    warning: no previously-included files matching '*pyc' found anywhere in distribution
    Skipping installation of /home/do3cc/.dev/example/lib/python2.7/site-packages/bobtemplates/__init__.py (namespace package)
    Installing /home/do3cc/.dev/example/lib/python2.7/site-packages/bobtemplates.plone-0.7.dev0-py2.7-nspkg.pth
Successfully installed bobtemplates.plone

So because it declared a namespace, it did not add an __init__.py file.
Then the code fails because, it expects to be able to to
import bobtemplates
bobtemplates.__file__

__file__ is only available if there is an __init__.py file in the module.
Should this actually be a namespace package?

this package now creates software with default GPLv2 "or later". To bring it in line with Plone standard, shouldn't that be GPLv2?

I've created a pull request for that at #59

Do we really need the IDefaultBrowserLayer from zope.publisher to create a package layer?

The example shonw on plone.browserlayer shows that is just using a plain interface from zope.interface...

/me wonders

Even for internal packages I do not bother to change the licence question to something other than GPL. We should get rid of that question as well. People can always change that if they want.

Opinions?

bin/test
results in

Traceback (most recent call last):
File "./bin/test", line 278, in
import zope.testing.testrunner
ImportError: No module named testing.testrunner

Not sure yet, why

See #42

see plone/Products.CMFPlone#811

Steps to reproduce:

$ ./bin/mrbob -O plone.app.contenttypes bobtemplates:plone_addon
$ cd plone.app.contenttypes
$ virtualenv-2.7 .
$ ./bin/python bootstrap-buildout.py
$ ./bin/buildout

bin/instanceand bin/test now contain the '/Users/philip/.cache/buildout/eggs/plone.app.contenttypes-1.2b3-py2.7.egg', instead of the new egg.

Why is this a issue? I want to test the 4.3-compatible version of plone.app.contenttypes because I'm backporting some features (https://github.com/plone/plone.app.contenttypes/tree/backport). For this I modified to buildout to follow the best-practices of bobtemplates.plone.

But now (and I guess for quite some time travis and local tests always test the released version and the package itself is ignored. I had the same problem with plone.app.linkintegrity.
The only way to get these instances to work is to use the coredev.

I remember that used to work at some point and cannot seem to figure out what is wrong. 😢

To include it better into docs.plone.org it would be better to follow http://docs.plone.org/about/documentation_styleguide_addons.html#id2 if that would be possible.
For now I have to copied it from hand, which we do not want to do, because we want to have up 2 date docs all the time.

What went wrong here? See https://travis-ci.org/plone/bobtemplates.plone

I usually run code-analysis with plone.recipe.codeanalysis on travis as a first step. This way the build fails as early as possible on pep8 violations etc.. This might sound strict but 100% compliance with code-analysis is the only way to make it work in my experience. People can always remove that if they don't agree but I would consider that our best practice. Opinions?

Here is an example implementation:

https://github.com/plone/plone.restapi/blob/master/.travis.yml
https://github.com/plone/plone.restapi/blob/master/travis.cfg#L19