Fix situation where a module name is identical to the package name

[Jan Wijbrand Kolman]

There're some issues when there is a module with a name identical to the package name using grok. People using grokproject will finf themselves in this situation by default.

This easily gets confusing with:

* registering templates.

* relative imports.

[Jan Wijbrand Kolman (janwijbrand)]

This issue is being discussed on the grok-dev list.

[Philipp von Weitershausen (philikon)]

Apart from the fact that we need to come up with a solution for the templates in case we have foo/foo.py, we should not encourage this situation for beginners in grokproject. I wonder what a good name for a start-out module would be (foo/foomodel.py? foo/model.py? foo/demo.py? ...)

[Philipp von Weitershausen (philikon)]

Preliminary fix was commited in r72234. grokproject now asks you for the name of the module it creates.

[Martijn Faassen (faassen)]

The issue in grokproject was solved (as remarked). The issue in grok itself maybe hasn't been solved yet so I'm leaving this open.

[Jan Wijbrand Kolman (janwijbrand)]

This issue has a partial fix in that grokproject will ask for a "main" module name. I think this is the best we can do in practical terms, as it really is a Python "thing" that having identical module names and package names can lead to import-confusion.

Can someone either follow-up on this issue, or close it? (IMHO it can really be closed)

[Philipp von Weitershausen (philikon)]

On 5 Nov 2007, at 10:27 , Jan Wijbrand Kolman wrote:
> This issue has a partial fix in that grokproject will ask for a "main"
> module name.

This isn't a fix, this is actually the cause for this problem. Let's
say somebody adds a HelloWorld sandbox and calls the "main" module
helloworld.py too:

   grokproject HelloWorld
   ... [app.py] helloworld.py

Then grokproject will create src/helloworld/helloworld.py along with
src/helloworld/helloworld_templates. Such a setup is currently
unsupported by grok. I think the view/templates grokker in particular
has its problems with it.

Apart from the fact that this bug persists in grok, I also think we
should get rid of asking the user for an alternative name of 'app.py'.
It should simply be app.py and basta. I've seen so many newbies just
entering anything here, even when I've told them over and over and
that they should simply hit enter.

[Christian Theune (ctheune)]

Am Montag, den 05.11.2007, 09:42 +0000 schrieb Philipp von
Weitershausen:
> Apart from the fact that this bug persists in grok, I also think we
> should get rid of asking the user for an alternative name of 'app.py'.
> It should simply be app.py and basta. I've seen so many newbies just
> entering anything here, even when I've told them over and over and
> that they should simply hit enter.

+1

--
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany
www.gocept.com - <email address hidden> - phone [phone] -
fax [phone] - zope and plone consulting and development

[Martijn Faassen (faassen)]

On 11/5/07, Christian Theune <email address hidden> wrote:
>
> Am Montag, den 05.11.2007, 09:42 +0000 schrieb Philipp von
> Weitershausen:
> > Apart from the fact that this bug persists in grok, I also think we
> > should get rid of asking the user for an alternative name of 'app.py'.
> > It should simply be app.py and basta. I've seen so many newbies just
> > entering anything here, even when I've told them over and over and
> > that they should simply hit enter.
>
> +1

+1. You can always add a commandline option to name it something else,
but not really necessary in my mind.

[Uli Fouquet (uli-gnufix)]

This issue still persists as Joachims complaint on grok-dev shows:

  http://permalink.gmane.org/gmane.comp.web.zope.grok.devel/4252

Even if the 'Enter module name' option vanishes from grokproject (I know it does), we still have the problem, that Grok incorrectly emits warnings (or even errors in current releases) on 'unassociated templates'.

So the problem reappears, when somebody creates a subpackage with a module named like the subpackage and views and templates in it. In fact it seems to me that we got an ambiguity problem here:

When a pkg 'foo' contains view classes (defined in __init__.py) and a module 'foo' and a template dir 'foo_templates', to which entitiy should the templates in foo_templates be associated? To the package or the same named module? Well, the answer for almost every case would be: to the module.

For templates this could be simply clarified in the template registry by not searching for templates of modules, that are packages. I've 'implemented' this (two lines of code plus tests) in the attached patch on the current grok trunk. The ambiguity would vanish at least for templates.

The 'drawback' would be, that one cannot register package-bound templates, which would be defined in __init__.py. This, however, would be bad style IMHO and I wouldn't care too much for this usecase. In fact I never tried to define views in __init__.py.

[Uli Fouquet (uli-gnufix)]

This is an improved version of the patch: less code, less typos.

If there are no objections, I will apply this patch on the trunk this weekend.

[Philipp von Weitershausen (philikon)]

On 5 Apr 2008, at 12:03 , Uli Fouquet wrote:
> This is an improved version of the patch: less code, less typos.
>
> If there are no objections, I will apply this patch on the trunk this
> weekend.

The patch looks good overall. I would just drop the comments about
"prior versions of Grok" and just make statements about the status-
quo. Just a minor nitpick, though. Thanks!

[Uli Fouquet (uli-gnufix)]

The problem is fixed now in trunk at least for identical module/package names and templates. Not sure about relative imports.