search

plone / bobtemplates.plone

Python Code Templates for Plone Projects with mr.bob
https://pypi.org/project/bobtemplates.plone/
GNU General Public License v2.0
24 stars 31 forks source link

cannot create top level namespace package #113

Closed thet closed 8 years ago

thet commented 8 years ago

bobtemplates.plone can only create two- or three- nested namespace package, not a top-level namespace project. It cannot, for example, create a project like yafowil - it errors with: Error: 'yafowil' is not a valid packagename.

It would be nice if this could be fixed easily - but it's a corner case. I'm ok with closing this issue, if it's not worth the effort...

do3cc commented 8 years ago

Just my opinion, but plone is very plone specific and I barely see top level packages for plone.

thet commented 8 years ago

True. Just had the this case, for the first time actually.

pbauer commented 8 years ago

I created a pull-request for this issue: https://github.com/plone/bobtemplates.plone/pull/118 It is not something I would advertise but I think it's nice to support it and the needed changes are small.

do3cc commented 8 years ago

But why add complexity to this package for a feature rarely used?

gforcada commented 8 years ago

@pbauer and you are missing adding that on the testing matrix at least :-)

pbauer commented 8 years ago

I agree it is a rare case but I wrote the code before the issue was closed. I just found and finished it now. Still if people write toplevel-packages it would be nice if they follow best-practices (which yafowil does not since it is wrongly declared as a namespace-package in https://github.com/bluedynamics/yafowil/blob/master/setup.py#L34 and thus needs a ugly line in https://github.com/bluedynamics/yafowil/blob/master/src/yafowil/__init__.py#L2

@gforcada the matrix does not test the different types at all, only Plone-version (4.3.7, 5.0) and package-types (i.e. Basic, Theme, Dexterity).

gforcada commented 8 years ago

@pbauer oh great, then that's fine with me (for anyone who care about my opinion that is :D)

do3cc commented 8 years ago

I am -1. It is feature creep. For a rarely used feature two methods get their code paths doubled. https://en.wikipedia.org/wiki/Cyclomatic_complexity I usually don't mind ifs, but not if they are for features that are really uncommon

tisto commented 8 years ago

I tend towards -1 as well because we need to be really careful with adding more complexity. Especially if we do not fully test the options that we have. Another question would be if we consider using namespaces to be best practice (which I think we do). If so a Plone package without a namespace would be bad practice and should not be supported by bobtemplates.plone.

thet commented 8 years ago

Just to illustrate the use case I had -- I wanted to create a project specific namespace package, e.g. superduper (fictional name). This would have provided basic functionality and a base API. Then I wanted to create optional addons to that package called superduper.views, superduper.locales, superduper.migration, etc. I think this is a valid use case and a nice and clean package structure.

@pbauer changes do not add much more complexity and it's even tested.

do3cc commented 8 years ago

This product is also about promoting best practices and Plone packages without a namespace are bad practice.

thet commented 8 years ago

A top level namespace is not a bad practice.

do3cc commented 8 years ago

I'd rather not have this discussion here. If you want this clarified, please do this on community.plone.org, where are more people listening.

thet commented 8 years ago

There is nothing to discuss about because I'm in right. ;)

do3cc commented 8 years ago

I really don't mind if you bring this issue on on community.plone.org, because the docs don't say anything about the reasons nor does martin aspelis Professional Plone 4 development say why he uses namespace packages. So there really might be an "Erkenntnisgewinn" But the statistics regarding using non namespace eggs for plone packages don't lie. It is not common practice

thet commented 8 years ago

I agree about that. But no, I don't feel like wanting to discuss this :)

do3cc commented 8 years ago

I just noticed something and paste it here: https://github.com/collective/buildout_helpers/blob/master/setup.py#L22 before somebody else digs through my commit history again and finds me contradicting.

The reason for not using a namespace package here is two fold:

  1. It's not a plone package, I don't need to follow no stinkin conventions
  2. It usually gets installed via pip, when you do this in a virtualenv, big confusion happens. It seems pip does not support namespace packages in the same way as buildout does...

@jensens re 2. point. I wonder why this causes no trouble with zc.buildout...