pydanny / cookiecutter-djangopackage

A cookiecutter template for creating reusable Django packages quickly.

Hi there 👋

• 🔭 I’m currently working for @octoenergy on decarbonizing the planet
• 😄 Pronouns: he/him
• 🐍 I code mostly in Python, but also some NodeJS and Rust
• 🌱 I’m currently learning Rust
• 🌎 Contact me if you want to join me in decarbonizing the planet
• 🥋 I'm currently training in Brazilian Jiu-Jitsu for sport and Tai Chi to help recover from a bike injury
• 📫 How to reach me:
  • mastodon
  • LinkedIn
  • twitter
• ⚡ Fun fact: I met my wife at PyCon US in 2010. She is awesome, her GH account is @audreyfeldroy

cookiecutter-djangopackage's Issues

Set up docs folder for the cookiecutter-djangopackage project

• Use Sphinx to create a docs/ folder
• Move parts of the README to different .rst files in docs/

Travis conf python versions causes build errors

The default Travis config will run tests with python 2.6 against django 1.8, which is not a supported version and therefore fails.

Remove Python 3.2

Django hasn't supported Python 3.2 in a while, not supported version works with it anymore.

Remove crate.io references on README.rst. crate.io domain was sold to bigdata company

Remove crate.io references on README.rst. crate.io domain was sold to bigdata company

http://www.reddit.com/r/Python/comments/1wcp93/what_happened_to_crateio/
crateio/crate.io#18

I think at the moment there is no substitute for crate.io.
Are developing a new pypi, which can be seen in [1]

I do not know if [1] it is the same as that documented in [2]

[1] https://preview-pypi.python.org/
[2] https://warehouse.readthedocs.org/

Typo in README.srt template

In Running Tests explanation:

pip install -r requirements-text.txt

Fix to requirements-test.txt

Add option for test_app to test models with relations to different package models.

1.Either add option in cookiecutter.json or do it by default and provide instructions for deletion if not needed.
2. Provide something like pydanny/dj-spam@a2700eb but more generic.
3. In the generated README, include instructions for using and extending it (for example, how to generate migrations).

Add appveyor support

See how cookiecutter-django does it.

Add support for `setUpTestData` in test template

Django 1.8 added support for the setUpTestData method which can speed up the execution of tests.

Between the weird capitalization of the method name and the fact that you need to remember to make it a classmethod, it often takes me a few tries to get it running properly.

I think having an empty one in the tempate would be useful and since there's already setUp and tearDown, I think it makes sense to have setUpTestData as well.

update generated project's CONTRIBUTING.rst to reflect what versions of Python & Django the project supports

see logic to get supported Python versions from Django versions here:
https://github.com/pydanny/cookiecutter-djangopackage/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/tox.ini

I ran into trouble formatting the list into something that reads correctly in English (adding "and" where needed and omitting it where not)

Write a test for autodoc

similar to #86

Get codecov working

Everything has been configured as far as I can tell, but @codecov isn't picking it up yet. #87 can't be completed yet until this has been resolved.

Add pytest-cookies

Reference: https://github.com/hackebrot/pytest-cookies

Repository URL in README

Currently the README uses this when running cookiecutter

$ cookiecutter https://github.com/pydanny/cookiecutter-dj-package.git

which should probably be

$ cookiecutter https://github.com/pydanny/cookiecutter-djangopackage.git

to reflect the current repository location instead, although the old one still works now (GitHub seems to maintain a redirection automatically).

Use a version manager tool instead of get_version()

Our current approach to getting the version number involves a custom get_version() that reads __init__py and parses it with a regexp: https://github.com/pydanny/cookiecutter-djangopackage/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/setup.py#L20-L29

It's better than importing the package to get the version (which causes chicken-egg problems), but really not ideal.

There are tools that can handle this for us:

• https://github.com/lgiordani/punch
• https://github.com/peritus/bumpversion

TODOs:

• Choose one of the above tools (or maybe one that I don't know about)
• Set it up with the generated package
• Remove old get_version() code
• Document how to increment versions with the chosen tool in docs/versioning.rst or wherever you think makes the most sense

'Testall' target doesn't exist.

If one runs:
make help and gets the help page, they would see: testall - run tests on every Python version with tox.

Using this target, one would recieve the error:

make: *** No rule to make target `testall'.  Stop.

The makefile help should be changed to match the correct target of test-all.

I created a pull request for this #41.

Testing using tox does nothing

Hi, I've used cookiecutter-djangopackage in some projects and I always have to change some config in tox.ini because tox config tries to run setup.py test and the only thing it does is a print a line instead of executing the tests.

The way I solve this is running runtests.py instead.

The pull request: #12

Add a script to generate initial migrations

Projects that install your package will generate them automatically, but it's nice to have an initial migration especially if you're deploying using a platform as a service

Multiple ways of publishing

• Date you used Cookiecutter DjangoPackage: 2016/09/01
• Cookiecutter version used, if known: Where's the info ?
• Python version: 2.7
• Operating System: Ubuntu

Description

I wanted to publish my package on PyPI

What I Did

I checked the files in my cookiecutter generated project to see if there was already a way of doing that. Turns out there are 2 :

make release

and

python setup.py publish

Both do more or less the same things but with differences (one checks for the wheel library.

Zen of python says "there should be one and preferably only one obvious way to do it".

There are two and it's confusing.

I'd make a pull request but I wanted to check first : should make publish just call python setup.py release or is there something else to it ?

Make django-model-utils optional based on if there are models

Add missing runtests.py code

Example django site folder

This template is awesome, however, every time that I use it, I find myself creating an example folder with a django installation inside so that I can develop and test. Would there be any interest in having an example django installation inside a folder which could allow for the app to be debugged right off the install?

Tox tests over different reason

Hello,

Thanks for great repo. I started up my project yet ( https://github.com/ad-m/django-teryt-tree ) using your starter.

I am would like why you don't provide tests over different version of django for travis or pull requests is well come? Is there any reason to don't tests by tox&travis over different version of django package?

Greetings,
Adam Dobrawy

Add an isort configuration to sort imports according to Django style guide

Django style guide and Two Scoops of Django suggest sorting imports in the following way:

1. Standard library imports
2. Imports from core Django.
3. Imports from third-party apps including those unrelated to Django.
   4. Imports from other Django apps in your project (not sure we can generate anything for this)
4. Local imports

We can use isort to do this sorting automatically. This commit should add an isort dependency in requirements_dev.txt, add an isort section in setup.cfg that sorts the imports correctly, and include instructions in CONTRIBUTING.rst for running isort before contributing.

Consider compacting the tox.ini env list

There's a way to specify a more compact list of tox environment variations. For example: https://github.com/maraujop/django-crispy-forms/blob/dev/tox.ini

Is this worth doing in cookiecutter-djangopackage? Thoughts?

🔔 @kelseyq

Update instructions to specify the need for a pypi account

• Date you used Cookiecutter DjangoPackage: today
• Cookiecutter version used, if known:
• Python version: 3.4
• Operating System: linux

Description

Offering a suggestion to update the instructions to specify a need for a pypi account. I used cookiecutter today to push my first django package to pypi and I got stuck on the register and publish steps, as it would allow me to register without any warnings or account and then spent lots of time wondering why I couldn't publish.

Also, I found this info on the pypirc file very helpful:
pipyrc documentation

Thanks for the great tool, it saved me hours overall!

Add test coverage

Missing Template Variable in CONTRIBUTING.rst

your_name_here could be filled in with {{ cookiecutter.github_username }} in CONTRIBUTING.rst

Btw, this was awesome.

Add Pep8 checker for rendered package

Review commit log and update CHANGELOG.md and contributors.rst

We've fallen behind in this task, catching up is important. People deserve credit for their work!

update Travis config to use appropriate Python versions given specified Django versions

see logic in tox.ini:
https://github.com/pydanny/cookiecutter-djangopackage/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/tox.ini

Consider creating a separate settings file for tests

I saw this in wagtail:
https://github.com/torchbox/wagtail/blob/master/runtests.py#L12
https://github.com/torchbox/wagtail/blob/master/wagtail/tests/settings.py

I'm currently packaging a complex-ish app that needs a decent amount of additions to settings to even run and it seems like a nice idea to package those settings with the tests--thoughts?

Update example usage in readme

The README still shows old-style cookiecutter prompts.

This might be confusing to some users.

Update the generated package's auto-generated Sphinx docs

There's been a new version of Sphinx since the docs in this template were generated! Let's get conf.py and the Makefile more up to date.

TODOS:

• Generate a sample package from this template
• Remove conf.py and Makefile from the generated package's docs folder
• Run 'sphinx quickstart' in that docs folder
• Review the changes and decide which ones need to be incorporated into our template

Add codecov

Providing easy hooks for codecov would be really nice for ensuring quality of projects.

Add instructions on how to add test-only models

I was trying to use some models only for my tests and it took me a while to figure it out.

In the end, I managed to do it by adding 'tests' to the INSTALLED_APPS in runtests.py. I'm not sure if that's the best way to go about it but it does seem to work in my case.

setup.py shouldn't import package

The setup.py file does an import on the package itself, in order to get the version.

This becomes an issue if doing "import mypackage" ends up importing other things, especially dependencies (e.g. mypackage/__init__.py imports mydependency directly or indirectly). The end result can be that setup.py cannot run unless dependencies are already installed.

This means that often a package become uninstallable (with something like pip, which runs setup.py to get a list of dependencies), unless dependencies are installed previously.

The problem is often not apparent to the package maintainer as well, because they rarely install the package from scratch.

If this is fixed, bumpversion config will also need to be fixed.

Add tests on cookiecutter-djangopackage itself

Reference: https://github.com/pydanny/cookiecutter-django/blob/master/tests/test_cookiecutter_generation.py

Add codecov to rendered package

Needs:

• Addition to generated travis-ci.yml
• Basic instructions for using codecov
• Badge in README.rst

The `open` order in make docs is not cross-platform

The docs target in the generated makefile contains a last order:

open docs/_build/html/index.html

that fails in Linux systems as open is generally a symbolic link to openvt, a utility for starting programs in virtual terminals.

The most similar thing in Linux that I know of would be xdg-open, althought there may be better alternatives, but certainly not open.

Expand stubbed tests in test_bake_project.py

See https://github.com/pydanny/cookiecutter-djangopackage/blob/master/tests/test_bake_project.py

Auto-version bumping

Possibly use:

• https://pypi.python.org/pypi/bumpversion
• https://github.com/mitsuhiko/flask/blob/master/scripts/make-release.py

Add tests for the rendering process

Reference: https://github.com/pydanny/cookiecutter-django/tree/master/tests

Refactor generating the setup.py

Any executable code in setup.py is risky. Rather than come up with clever code to handle finding packages, there should be a make_release.py module that auto-generates each release's setup.py with hard-coded values.

TODO: Look at Flask's make_release.py to see what Armin does.

Add instructions for generating autodoc to generated package's contributors instructions

http://www.sphinx-doc.org/en/stable/ext/autodoc.html

Add Codecov badge

reference: https://codecov.io/gh/pydanny/cookiecutter-djangopackage/settings/badge

Managing project specific settings

This is a request for enhancement. It would be good to provide an out of the box wire-up for a couple of package-specific settings. I've looked through a few and each of them seems to have a slightly different convention and way to manage settings ( django-rest-framework has settings.py with DEFAULTS dict, django-cors-headers has defaults.py with settings dict etc )
Not sure if there is a recommended way of doing one or the other, but this would be very handy to have out of the box.
If anyone has a good suggestion on how to wire this, i'll do a pull request

Provide option to use py.test instead of unittest

This needs to be an option, not mandatory.

Add license options

See cookiecutter-django for options.

Add Django-specific instruction to installation.rst

Add an instruction in installation.rst that tells users to add {{ package_name }} to their INSTALLED_APPS setting in their Django project

Add django-test-plus and test that all views are good

• Add the latest django-test-plus to {{cookiecutter.repo_name}}/requirements_test.txt
• In {{cookiecutter.repo_name}}/tests/test_views.py, call view.assertGoodView() for each auto-generated view. See https://github.com/revsys/django-test-plus#assertgoodviewcls-initkwargsnone-args-kwargs