Deprecate Fuzzy Attributes that are already supported in Faker

[jeffwidman]

I'd like to start a conversation around deprecating and eventually removing the Fuzzy Attributes that are already supported by Faker: http://factoryboy.readthedocs.org/en/latest/fuzzy.html

Reasoning:
I'd prefer to limit the scope of FactoryBoy to handling turning input data into models, including complicated scenarios like chaining. And then delegate the fuzzing of the data as much as possible to external libraries like Faker.

Since we now wrap Faker, there's no reason for us to provide FuzzyAttributes that are already provided by Faker--it's just duplicated work. For any duplicate FuzzyAttributes that are more powerful than their Faker equivalents, where possible, I'd rather see that code moved over to Faker.

@rbarrois your thoughts?

[rbarrois]

Excellent idea! This made sense as long as faker wasn't supported or optional; but it's now providing a much better fuzzer for many functions.

We'll have to be careful on the upgrade path though — a backwards compatibility policy will soon be needed!

[jeffwidman]

Cool. Assuming this project is semvar, I think the todo's here are:

• add deprecation note in docs immediately.
• go through the fuzzy implementations and make sure the faker equivalent is at least as powerful; if not, submit that code as a PR to faker
• actually remove the code as part of a 3.x.x release since it's a backwards incompatible change.

Could certainly handle it differently, but that's the route I'd go down for fast and easy. I'll try to start working on this, as I suspect getting things into a published Faker release might take a little while.

[abendebury]

It seems that faker lacks a provider to pick a random choice out a of a list, like fuzzy.FuzzyChoice does.

[MichaelAquilina]

I have also noticed that faker doesnt have an equivalent for FuzzyChoice. What's the recommended route. Should you use FuzzyChoice in that case or resort to creating your own in order to avoid using any fuzzy attributes?

[arugifa]

Since fuzzy attributes (will) rely on an external dependency, what do you think about making their support optional? By putting something like extras_require = {'Fuzzy': ['fake-factory']} in setup.py.

[rbarrois]

@alexandre-figura factory_boy already has a non-optional dependency on faker ;)

[rhunwicks]

@PlasmaSheep said:

It seems that faker lacks a provider to pick a random choice out a of a list, like fuzzy.FuzzyChoice does

That's true. In the meantime, I have this:

TYPES = [e[0] for e in my_model.TYPE_CHOICES]

class MyFactory(factory.django.DjangoModelFactory):

    type = factory.Faker('random_element', elements=TYPES)

It doesn't work if you put the list comprehension directly into the factory.Faker call

[chrislawlor]

Regarding the missing FuzzyChoice equivalent in Faker, you can avoid having to create new lists of valid choices by adding a new provider to the bundled Faker:

# somefile.py
class ChoiceProvider(BaseProvider):
    def random_choice(self, choices=None):
        """
        Given a list of choices in Django format, return a random value
        """
        choice = self.random_element(choices)
        return choice[0]

You then have to add the new provider:

from somefile import ChoiceProvider
factory.Faker.add_provider(ChoiceProvider)

Once the new provider has been added, use it like this:

class MyFactory(factory.django.DjangoModelFactory):
    choice_field = factory.Faker('random_choice', choices=mymodel.CHOICE_FIELD_CHOICES)

Having to include the add_provider boilerplate in all your factory files is a bit sub-optimal.
Personally, I feel it is a simple enough class that it could be added directly to factory boy instead of submitted as a PR to faker. I'm just not sure that it provides any value to faker outside the context of a django project using factory boy, so they'd be hesitant to accept it. I'd be happy to submit a PR here if anyone would like.