get_class fails with top level packages.

[maiksprenger]

Hello.
In an attemp to extend the shipping "app" we came into a problem.

We copied the shipping package into our project's package. So we have
MyProject/
shipping/
repository.py
MyProject/
settings.py
....

But after several tries and debugging, the get_class (and more precisely, get_classes) in oscar/core/loading.py was not picking the classes in this package and son, it defaulted to the oscar's system wide shipping module.

After a grep in oscar, it seems that everytime that Repository is required, it is loaded with get_classs. So it should not need any additional bonding other than overriding in INSTALLED_APPS:

INSTALLED_APPS = INSTALLED_APPS + get_core_apps(['shipping'])

It turns out that when get_classes generating the module path, if it is a top level package, it will generate something like : shipping.shipping.repository instead of shipping.repository.

The problem is that _get_app_module_path assumes there's always a dot in the module's name. get_classes should check that there is a dot in the module label before calling _get_app_module_path.

[codeinthehole]

Yes, this is a known issue. Oscar assumes you are using apps packages as somepackage.myapp.

I'll make sure this is documented properly.

Thanks for reporting.

[maiksprenger]

Nobody likes writing documentation, and it's easy enough to fix ;)

[codeinthehole]

@maikhoepfel Could you write some tests to verify this behaviour?

[maiksprenger]

Okay, added some tests.