Defer Django and sqlalchemy imports

[adamchainz]

Fixes #1070.

[adamchainz]

These two submodules don’t have any library-specific imports, so the try/except was never needed.

[francoisfreitag]

Hi!

Thanks for offering a PR! 🌟

I think these imports are here to allow code such as import factory; factory.mogo.MogoFactory().

Conversely, users who have django as a dependency but do not use it would probably rather avoid loading django at all.

I have suggested such a simplification in the past #760 (see the discussion there) and follow up #766. It was rejected on the basis that it would break imports for users.

Arguably, this code pattern should not have been supported in the first place. I’m still of the opinion this change should land (maybe with a deprecation period to reduce friction for users).

This PR adds another good argument: performance.

[francoisfreitag]

Oopsie, I now realize I missed line 5 : from . import alchemy, mogo, mongoengine. Edited my previous comment.

Your suggested change is much less controversial then. :)

[francoisfreitag]

I’m wondering if the same change should be applied to the django module?

[adamchainz]

Yeah, good idea. I didn’t do it at first out of laziness. I just made the change and it wasn’t that hard!

[rbarrois]

I understand the idea behind this change; however, I would prefer to have an agreement on the overall design (in the issue) before jumping into code.

At a high level, I would be OK with this kind of change if:

• It doesn't require any change on current working code;
• It doesn't scatter import statements throughout the codebase;
• It breaks cleanly at module import time, not at runtime — i.e as soon as one declares a DjangoModelFactory / AlchemyModelFactory / etc, not one they get used.

Would it be possible to adjust this idea to match those? I'd rather avoid increasing the burden on maintenance for the library — including issues opened by users who don't understand why they get import errors when calling their factories…