[Python-modules-commits] [python-model-mommy] 01/03: Import python-model-mommy_1.2.6.orig.tar.gz
Edward Betts
edward at moszumanska.debian.org
Tue May 31 08:32:23 UTC 2016
This is an automated email from the git hooks/post-receive script.
edward pushed a commit to branch master
in repository python-model-mommy.
commit 6b110a46df981682878c56a1eeaf6041f90ca5a7
Author: Edward Betts <edward at 4angle.com>
Date: Tue May 31 07:32:18 2016 +0100
Import python-model-mommy_1.2.6.orig.tar.gz
---
PKG-INFO | 441 ++------------------------------------
README.rst | 432 ++-----------------------------------
model_mommy.egg-info/PKG-INFO | 441 ++------------------------------------
model_mommy.egg-info/SOURCES.txt | 1 +
model_mommy.egg-info/requires.txt | 5 +-
model_mommy/__init__.py | 2 +-
model_mommy/exceptions.py | 5 +
model_mommy/generators.py | 69 +++++-
model_mommy/mommy.py | 253 +++++++++++++++-------
model_mommy/recipe.py | 100 ++++++++-
model_mommy/timezone.py | 5 +-
model_mommy/utils.py | 33 +++
requirements.txt | 5 +-
setup.py | 10 +-
14 files changed, 451 insertions(+), 1351 deletions(-)
diff --git a/PKG-INFO b/PKG-INFO
index 98873bf..8461898 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: model_mommy
-Version: 1.2
+Version: 1.2.6
Summary: Smart object creation facility for Django.
Home-page: http://github.com/vandersonmota/model_mommy
Author: vandersonmota
@@ -14,434 +14,32 @@ Description: ============================================
With a simple and powerful API you can create many objects with a single line of code.
.. image:: https://travis-ci.org/vandersonmota/model_mommy.png?branch=master
- :target: https://travis-ci.org/vandersonmota/model_mommy
+ :target: https://travis-ci.org/vandersonmota/model_mommy
+ :alt: Test Status
- Install
- =======
-
- .. code-block:: console
-
- pip install model_mommy
-
-
- Basic usage
- ===========
-
- Let's say you have an app **family** with a model like this:
-
- .. code-block:: python
-
- class Kid(models.Model):
- happy = models.BooleanField()
- name = models.CharField(max_length=30)
- age = models.IntegerField()
- bio = models.TextField()
- wanted_games_qtd = models.BigIntegerField()
- birthday = models.DateField()
- appointment = models.DateTimeField()
-
- To create a persisted instance, just call *Mommy*:
-
- .. code-block:: python
-
- from model_mommy import mommy
- from family.models import Kid
-
- kid = mommy.make(Kid)
-
- No need to pass attributes every damn time.
-
- Importing every model over and over again is boring. So let *Mommy* import them for you:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- # 1st form: app_label.model_name
- kid = mommy.make('family.Kid')
-
- # 2nd form: model_name
- dog = mommy.make('Dog')
-
-
- .. [1] You can only use the 2nd form on unique model names. If you have an app
- *family* with a *Dog*, and an app *farm* with a *Dog*, you must use the
- `app_label.model_name` form.
-
- .. [2] `model_name` is case insensitive.
-
-
- Model Relationships
- -------------------
-
- *Mommy* also handles relationships. Say the kid has a dog:
-
- .. code-block:: python
-
- class Dog(models.Model):
- owner = models.ForeignKey('Kid')
-
- when you ask *Mommy*:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- rex = mommy.make('family.Dog')
-
- She will also create the `Kid`, automagically.
-
-
- Defining some attributes
- ------------------------
-
- Of course it's possible to explicitly set values for attributes.
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- another_kid = mommy.make('family.Kid', age=3)
-
- Related objects attributes are also reachable:
-
- .. code-block:: python
+ .. image:: https://pypip.in/v/model_mommy/badge.png
+ :target: https://crate.io/packages/model_mommy/
+ :alt: Latest PyPI version
- from model_mommy import mommy
+ .. image:: https://pypip.in/d/model_mommy/badge.png
+ :target: https://crate.io/packages/model_mommy/
+ :alt: Number of PyPI downloads
- bobs_dog = mommy.make('family.Dog', owner__name='Bob')
+ .. image:: https://img.shields.io/gratipay/vandersonmota.svg?style=social&label=Donate
+ :target: https://www.gratipay.com/vandersonmota
-
- Non persistent objects
- ----------------------
-
- If don't need a persisted object, *Mommy* can handle this for you as well:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- kid = mommy.prepare('family.Kid')
-
- It works like `make`, but it doesn't persist the instance.
-
- More than one instance
- ----------------------
-
- If you need to create more than one instance of the model, you can use the `_quantity` parameter for it:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- kids = mommy.make('family.Kid', _quantity=3)
- assert len(kids) == 3
-
- It also works with `prepare`:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- kids = mommy.prepare('family.Kid', _quantity=3)
- assert len(kids) == 3
-
- How mommy behaves?
- ==================
-
- By default, *model-mommy* skips fields with `null=True` or `blank=True`. Also if a field has a *default* value, it will be used.
-
- You can override this behavior by explicitly defining values.
-
-
- When shouldn't you let mommy generate things for you?
- -----------------------------------------------------
-
- If you have fields with special validation, you should set their values by yourself.
-
- *Model-mommy* should handle fields that:
-
- 1. don't matter for the test you're writing;
- 2. don't require special validation (like unique, etc);
- 3. are required to create the object.
-
-
- Currently supported fields
- --------------------------
-
- * BooleanField, IntegerField, BigIntegerField, SmallIntegerField, PositiveIntegerField, PositiveSmallIntegerField, FloatField, DecimalField
- * CharField, TextField, SlugField, URLField, EmailField
- * ForeignKey, OneToOneField, ManyToManyField (even with through model)
- * DateField, DateTimeField, TimeField
- * FileField, ImageField
-
- Custom fields
- -------------
-
- Model-mommy allows you to define generators methods for your custom fields or overrides its default generators. This could be achieved by specifing a dict on settings that its keys are the field paths and the values their generators functions, as the example bellow:
-
- .. code-block:: python
-
- # on your settings.py file:
- def gen_func():
- return 'value'
-
- MOMMY_CUSTOM_FIELDS_GEN = {
- 'test.generic.fields.CustomField': gen_func,
- }
-
- Recipes
+ Install
=======
- If you're not confortable with random data or even you just want to improve the semantics of the generated data, there's hope for you.
-
- You can define a **recipe**, which is a set of rules to generate data for your models. Create a module called `mommy_recipes.py` at your app's root directory:
-
- .. code-block:: python
-
- from model_mommy.recipe import Recipe
- from family.models import Person
-
- person = Recipe(Person,
- name = 'John Doe',
- nickname = 'joe',
- age = 18,
- birthday = date.today(),
- appointment = datetime.now()
- )
-
- Note you don't have to declare all the fields if you don't want to. Omitted fields will be generated automatically.
-
- The variable `person` serves as the recipe name:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- mommy.make_recipe('family.person')
-
- Or if you don't want a persisted instance:
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- mommy.prepare_recipe('family.person')
-
- You can use the `_quantity` parameter as well if you want to create more than one object from a single recipe.
-
-
- You can define recipes locally to your module or test case as well. This can be useful for cases where a particular set of values may be unique to a particular test case, but used repeatedly there.
-
- .. code-block:: python
-
- company_recipe = Recipe(Company, name='WidgetCo')
-
- class EmployeeTest(TestCase):
- def setUp(self):
- self.employee_recipe = Recipe(
- Employee, name=seq('Employee '),
- company=company_recipe.make())
-
- def test_employee_list(self):
- self.employee_recipe.make(_quantity=3)
- # test stuff....
-
- def test_employee_tasks(self):
- employee1 = self.employee_recipe.make()
- task_recipe = Recipe(Task, employee=employee1)
- task_recipe.make(status='done')
- task_recipe.make(due_date=datetime(2014, 1, 1))
- # test stuff....
-
-
- Recipes with foreign keys
- -------------------------
-
- You can define `foreign_key` relations:
-
- .. code-block:: python
-
- from model_mommy.recipe import Recipe, foreign_key
- from family.models import Person, Dog
-
-
- person = Recipe(Person,
- name = 'John Doe',
- nickname = 'joe',
- age = 18,
- birthday = date.today(),
- appointment = datetime.now()
- )
-
- dog = Recipe(Dog,
- breed = 'Pug',
- owner = foreign_key(person)
- )
-
- Notice that `person` is a *recipe*.
-
- You may be thinking: "I can put the Person model instance directly in the owner field". That's not recommended.
-
- Using the `foreign_key` is important for 2 reasons:
-
- * Semantics. You'll know that attribute is a foreign key when you're reading;
- * The associated instance will be created only when you call `make_recipe` and not during recipe definition;
-
-
- Recipes with callables
- ----------------------
-
- It's possible to use *callables* as recipe's attribute value.
-
- .. code-block:: python
-
- from datetime import date
- from model_mommy.recipe import Recipe
- from family.models import Person
-
- person = Recipe(Person,
- birthday = date.today,
- )
-
- When you call `make_recipe`, *Mommy* will set the attribute to the value returned by the callable.
-
- Sequences in recipes
- ----------------------
-
- Sometimes, you have a field with an unique value and using `make` can cause random errors. Also, passing an attribute value just to avoid uniqueness validation problems can be tedious. To solve this you can define a sequence with `seq`
-
- .. code-block:: python
-
-
- from model_mommy.recipe import Recipe, seq
- from family.models import Person
-
- person = Recipe(Person,
- name = seq('Joe'),
- age = seq(15)
- )
-
- p = mommy.make_recipe('myapp.person')
- p.name
- >>> 'Joe1'
- p.age
- >>> 16
-
- p = mommy.make_recipe('myapp.person')
- p.name
- >>> 'Joe2'
- p.age
- >>> 17
-
- This will append a counter to strings to avoid uniqueness problems and it will sum the counter with numerical values.
-
-
- You can also provide an optional `increment_by` argument which will modify incrementing behaviour. This can be an integer, float or Decimal.
-
- .. code-block:: python
-
-
- person = Recipe(Person,
- age = seq(15, increment_by=3)
- height_ft = seq(5.5, increment_by=.25)
- )
-
- p = mommy.make_recipe('myapp.person')
- p.age
- >>> 18
- p.height_ft
- >>> 5.75
-
- p = mommy.make_recipe('myapp.person')
- p.age
- >>> 21
- p.height_ft
- >>> 6.0
-
-
- Overriding recipe definitions
- -----------------------------
-
- Passing values when calling `make_recipe` or `prepare_recipe` will override the recipe rule.
-
- .. code-block:: python
-
- from model_mommy import mommy
-
- mommy.make_recipe('model_mommy.person', name='Peter Parker')
-
- This is useful when you have to create multiple objects and you have some unique field, for instance.
-
-
- Deprecation Warnings
- ====================
-
- Because of the changes of model_mommy's API, the following methods are deprecated and will be removed in one of the future releases:
-
- * `mommy.make_one` -> should use the method `mommy.make` instead
- * `mommy.prepare_one` -> should use the method `mommy.prepare` instead
- * `mommy.make_many` -> should use the method `mommy.make` with the `_quantity` parameter instead
- * `mommy.make_many_from_recipe` -> should use the method `mommy.make_recipe` with the `_quantity` parameter instead
-
- Known Issues
- ============
-
- django-taggit
- -------------
-
- Model-mommy identifies django-taggit's `TaggableManager` as a normal Django field, which can lead to errors:
-
- .. code-block:: pycon
-
- TypeError: <class 'taggit.managers.TaggableManager'> is not supported by mommy.
-
- The fix for this is to set ``blank=True`` on your ``TaggableManager``.
-
- Extensions
- ==========
-
- GeoDjango
- ---------
- Works with it? This project has some custom generators for it:
- https://github.com/sigma-consultoria/mommy_spatial_generators
-
-
- Contributing
- ============
-
- 1. Prepare a virtual environment.
-
- .. code-block:: console
-
- pip install virtualenvwrapper
- mkvirtualenv --no-site-packages --distribute
-
- 2. Install the requirements.
-
- .. code-block:: console
-
- pip install -r requirements.txt
-
- 3. Run the tests.
-
.. code-block:: console
- make test
-
-
- Inspiration
- ===========
-
- *Model-mommy* was inspired by many great open source software like ruby's ObjectDaddy and FactoryGirl.
-
+ pip install model_mommy
- Doubts? Loved it? Hated it? Suggestions?
- ========================================
- Join our mailing list for support, development and ideas!
+ Usage and Info
+ ==============
- * https://groups.google.com/group/model-mommy
+ * http://model-mommy.readthedocs.org/
Keywords: django testing factory python
Platform: UNKNOWN
@@ -450,3 +48,10 @@ Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Operating System :: OS Independent
Classifier: Topic :: Software Development
+Classifier: Programming Language :: Python :: 2
+Classifier: Programming Language :: Python :: 2.6
+Classifier: Programming Language :: Python :: 2.7
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.2
+Classifier: Programming Language :: Python :: 3.3
+Classifier: Programming Language :: Python :: 3.4
diff --git a/README.rst b/README.rst
index 1ce802c..f65051f 100644
--- a/README.rst
+++ b/README.rst
@@ -6,431 +6,29 @@ Model Mommy: Smart fixtures for better tests
With a simple and powerful API you can create many objects with a single line of code.
.. image:: https://travis-ci.org/vandersonmota/model_mommy.png?branch=master
- :target: https://travis-ci.org/vandersonmota/model_mommy
+ :target: https://travis-ci.org/vandersonmota/model_mommy
+ :alt: Test Status
-Install
-=======
-
-.. code-block:: console
-
- pip install model_mommy
-
-
-Basic usage
-===========
-
-Let's say you have an app **family** with a model like this:
-
-.. code-block:: python
-
- class Kid(models.Model):
- happy = models.BooleanField()
- name = models.CharField(max_length=30)
- age = models.IntegerField()
- bio = models.TextField()
- wanted_games_qtd = models.BigIntegerField()
- birthday = models.DateField()
- appointment = models.DateTimeField()
-
-To create a persisted instance, just call *Mommy*:
-
-.. code-block:: python
-
- from model_mommy import mommy
- from family.models import Kid
-
- kid = mommy.make(Kid)
-
-No need to pass attributes every damn time.
-
-Importing every model over and over again is boring. So let *Mommy* import them for you:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- # 1st form: app_label.model_name
- kid = mommy.make('family.Kid')
-
- # 2nd form: model_name
- dog = mommy.make('Dog')
-
-
-.. [1] You can only use the 2nd form on unique model names. If you have an app
- *family* with a *Dog*, and an app *farm* with a *Dog*, you must use the
- `app_label.model_name` form.
-
-.. [2] `model_name` is case insensitive.
-
-
-Model Relationships
--------------------
-
-*Mommy* also handles relationships. Say the kid has a dog:
-
-.. code-block:: python
-
- class Dog(models.Model):
- owner = models.ForeignKey('Kid')
-
-when you ask *Mommy*:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- rex = mommy.make('family.Dog')
-
-She will also create the `Kid`, automagically.
-
-
-Defining some attributes
-------------------------
-
-Of course it's possible to explicitly set values for attributes.
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- another_kid = mommy.make('family.Kid', age=3)
-
-Related objects attributes are also reachable:
-
-.. code-block:: python
+.. image:: https://pypip.in/v/model_mommy/badge.png
+ :target: https://crate.io/packages/model_mommy/
+ :alt: Latest PyPI version
- from model_mommy import mommy
+.. image:: https://pypip.in/d/model_mommy/badge.png
+ :target: https://crate.io/packages/model_mommy/
+ :alt: Number of PyPI downloads
- bobs_dog = mommy.make('family.Dog', owner__name='Bob')
+.. image:: https://img.shields.io/gratipay/vandersonmota.svg?style=social&label=Donate
+ :target: https://www.gratipay.com/vandersonmota
-
-Non persistent objects
-----------------------
-
-If don't need a persisted object, *Mommy* can handle this for you as well:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- kid = mommy.prepare('family.Kid')
-
-It works like `make`, but it doesn't persist the instance.
-
-More than one instance
-----------------------
-
-If you need to create more than one instance of the model, you can use the `_quantity` parameter for it:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- kids = mommy.make('family.Kid', _quantity=3)
- assert len(kids) == 3
-
-It also works with `prepare`:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- kids = mommy.prepare('family.Kid', _quantity=3)
- assert len(kids) == 3
-
-How mommy behaves?
-==================
-
-By default, *model-mommy* skips fields with `null=True` or `blank=True`. Also if a field has a *default* value, it will be used.
-
-You can override this behavior by explicitly defining values.
-
-
-When shouldn't you let mommy generate things for you?
------------------------------------------------------
-
-If you have fields with special validation, you should set their values by yourself.
-
-*Model-mommy* should handle fields that:
-
-1. don't matter for the test you're writing;
-2. don't require special validation (like unique, etc);
-3. are required to create the object.
-
-
-Currently supported fields
---------------------------
-
-* BooleanField, IntegerField, BigIntegerField, SmallIntegerField, PositiveIntegerField, PositiveSmallIntegerField, FloatField, DecimalField
-* CharField, TextField, SlugField, URLField, EmailField
-* ForeignKey, OneToOneField, ManyToManyField (even with through model)
-* DateField, DateTimeField, TimeField
-* FileField, ImageField
-
-Custom fields
--------------
-
-Model-mommy allows you to define generators methods for your custom fields or overrides its default generators. This could be achieved by specifing a dict on settings that its keys are the field paths and the values their generators functions, as the example bellow:
-
-.. code-block:: python
-
- # on your settings.py file:
- def gen_func():
- return 'value'
-
- MOMMY_CUSTOM_FIELDS_GEN = {
- 'test.generic.fields.CustomField': gen_func,
- }
-
-Recipes
+Install
=======
-If you're not confortable with random data or even you just want to improve the semantics of the generated data, there's hope for you.
-
-You can define a **recipe**, which is a set of rules to generate data for your models. Create a module called `mommy_recipes.py` at your app's root directory:
-
-.. code-block:: python
-
- from model_mommy.recipe import Recipe
- from family.models import Person
-
- person = Recipe(Person,
- name = 'John Doe',
- nickname = 'joe',
- age = 18,
- birthday = date.today(),
- appointment = datetime.now()
- )
-
-Note you don't have to declare all the fields if you don't want to. Omitted fields will be generated automatically.
-
-The variable `person` serves as the recipe name:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- mommy.make_recipe('family.person')
-
-Or if you don't want a persisted instance:
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- mommy.prepare_recipe('family.person')
-
-You can use the `_quantity` parameter as well if you want to create more than one object from a single recipe.
-
-
-You can define recipes locally to your module or test case as well. This can be useful for cases where a particular set of values may be unique to a particular test case, but used repeatedly there.
-
-.. code-block:: python
-
- company_recipe = Recipe(Company, name='WidgetCo')
-
- class EmployeeTest(TestCase):
- def setUp(self):
- self.employee_recipe = Recipe(
- Employee, name=seq('Employee '),
- company=company_recipe.make())
-
- def test_employee_list(self):
- self.employee_recipe.make(_quantity=3)
- # test stuff....
-
- def test_employee_tasks(self):
- employee1 = self.employee_recipe.make()
- task_recipe = Recipe(Task, employee=employee1)
- task_recipe.make(status='done')
- task_recipe.make(due_date=datetime(2014, 1, 1))
- # test stuff....
-
-
-Recipes with foreign keys
--------------------------
-
-You can define `foreign_key` relations:
-
-.. code-block:: python
-
- from model_mommy.recipe import Recipe, foreign_key
- from family.models import Person, Dog
-
-
- person = Recipe(Person,
- name = 'John Doe',
- nickname = 'joe',
- age = 18,
- birthday = date.today(),
- appointment = datetime.now()
- )
-
- dog = Recipe(Dog,
- breed = 'Pug',
- owner = foreign_key(person)
- )
-
-Notice that `person` is a *recipe*.
-
-You may be thinking: "I can put the Person model instance directly in the owner field". That's not recommended.
-
-Using the `foreign_key` is important for 2 reasons:
-
-* Semantics. You'll know that attribute is a foreign key when you're reading;
-* The associated instance will be created only when you call `make_recipe` and not during recipe definition;
-
-
-Recipes with callables
-----------------------
-
-It's possible to use *callables* as recipe's attribute value.
-
-.. code-block:: python
-
- from datetime import date
- from model_mommy.recipe import Recipe
- from family.models import Person
-
- person = Recipe(Person,
- birthday = date.today,
- )
-
-When you call `make_recipe`, *Mommy* will set the attribute to the value returned by the callable.
-
-Sequences in recipes
-----------------------
-
-Sometimes, you have a field with an unique value and using `make` can cause random errors. Also, passing an attribute value just to avoid uniqueness validation problems can be tedious. To solve this you can define a sequence with `seq`
-
-.. code-block:: python
-
-
- from model_mommy.recipe import Recipe, seq
- from family.models import Person
-
- person = Recipe(Person,
- name = seq('Joe'),
- age = seq(15)
- )
-
- p = mommy.make_recipe('myapp.person')
- p.name
- >>> 'Joe1'
- p.age
- >>> 16
-
- p = mommy.make_recipe('myapp.person')
- p.name
- >>> 'Joe2'
- p.age
- >>> 17
-
-This will append a counter to strings to avoid uniqueness problems and it will sum the counter with numerical values.
-
-
-You can also provide an optional `increment_by` argument which will modify incrementing behaviour. This can be an integer, float or Decimal.
-
-.. code-block:: python
-
-
- person = Recipe(Person,
- age = seq(15, increment_by=3)
- height_ft = seq(5.5, increment_by=.25)
- )
-
- p = mommy.make_recipe('myapp.person')
- p.age
- >>> 18
- p.height_ft
- >>> 5.75
-
- p = mommy.make_recipe('myapp.person')
- p.age
- >>> 21
- p.height_ft
- >>> 6.0
-
-
-Overriding recipe definitions
------------------------------
-
-Passing values when calling `make_recipe` or `prepare_recipe` will override the recipe rule.
-
-.. code-block:: python
-
- from model_mommy import mommy
-
- mommy.make_recipe('model_mommy.person', name='Peter Parker')
-
-This is useful when you have to create multiple objects and you have some unique field, for instance.
-
-
-Deprecation Warnings
-====================
-
-Because of the changes of model_mommy's API, the following methods are deprecated and will be removed in one of the future releases:
-
- * `mommy.make_one` -> should use the method `mommy.make` instead
- * `mommy.prepare_one` -> should use the method `mommy.prepare` instead
- * `mommy.make_many` -> should use the method `mommy.make` with the `_quantity` parameter instead
- * `mommy.make_many_from_recipe` -> should use the method `mommy.make_recipe` with the `_quantity` parameter instead
-
-Known Issues
-============
-
-django-taggit
--------------
-
-Model-mommy identifies django-taggit's `TaggableManager` as a normal Django field, which can lead to errors:
-
-.. code-block:: pycon
-
- TypeError: <class 'taggit.managers.TaggableManager'> is not supported by mommy.
-
-The fix for this is to set ``blank=True`` on your ``TaggableManager``.
-
-Extensions
-==========
-
-GeoDjango
----------
-Works with it? This project has some custom generators for it:
-https://github.com/sigma-consultoria/mommy_spatial_generators
-
-
-Contributing
-============
-
-1. Prepare a virtual environment.
-
-.. code-block:: console
-
- pip install virtualenvwrapper
- mkvirtualenv --no-site-packages --distribute
-
-2. Install the requirements.
-
-.. code-block:: console
-
- pip install -r requirements.txt
-
-3. Run the tests.
-
.. code-block:: console
- make test
-
-
-Inspiration
-===========
-
-*Model-mommy* was inspired by many great open source software like ruby's ObjectDaddy and FactoryGirl.
-
+ pip install model_mommy
-Doubts? Loved it? Hated it? Suggestions?
-========================================
-Join our mailing list for support, development and ideas!
+Usage and Info
+==============
-* https://groups.google.com/group/model-mommy
+* http://model-mommy.readthedocs.org/
diff --git a/model_mommy.egg-info/PKG-INFO b/model_mommy.egg-info/PKG-INFO
index b34e45b..fab6884 100644
--- a/model_mommy.egg-info/PKG-INFO
+++ b/model_mommy.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: model-mommy
-Version: 1.2
+Version: 1.2.6
Summary: Smart object creation facility for Django.
Home-page: http://github.com/vandersonmota/model_mommy
Author: vandersonmota
@@ -14,434 +14,32 @@ Description: ============================================
With a simple and powerful API you can create many objects with a single line of code.
.. image:: https://travis-ci.org/vandersonmota/model_mommy.png?branch=master
- :target: https://travis-ci.org/vandersonmota/model_mommy
+ :target: https://travis-ci.org/vandersonmota/model_mommy
+ :alt: Test Status
- Install
- =======
-
- .. code-block:: console
-
- pip install model_mommy
-
-
- Basic usage
- ===========
-
- Let's say you have an app **family** with a model like this:
-
- .. code-block:: python
-
- class Kid(models.Model):
- happy = models.BooleanField()
- name = models.CharField(max_length=30)
- age = models.IntegerField()
- bio = models.TextField()
- wanted_games_qtd = models.BigIntegerField()
- birthday = models.DateField()
- appointment = models.DateTimeField()
-
- To create a persisted instance, just call *Mommy*:
-
- .. code-block:: python
-
- from model_mommy import mommy
- from family.models import Kid
-
- kid = mommy.make(Kid)
-
- No need to pass attributes every damn time.
... 1306 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-model-mommy.git
More information about the Python-modules-commits
mailing list