Initial django scaffold

[brylie]

Note: work-in-progress

Create initial project scaffold.

Todo

• environment variable for secret key
• developer set-up instructions in README
• settings for database
• conditional django-debug-toolbar setting
• debug environment variable

[brylie]

@Nick-Hall, it might be useful to have a 'work-in-progress' label (e.g. bright orange) to indicate that a PR is still under construction.

[brylie]

Thanks @Nick-Hall

Also, I realize that Gramps uses Mantis for the primary bug tracker. However, would it be permissible to use GitHub issues to manage this project roadmap? That way, I can quickly create issues, document the design considerations, and link them to a related pull-request from a single interface.

[Nick-Hall]

OK. I have enabled GitHub Issues for this repository. We probably don't need the features of Mantis at this point.

However, I suggest we use the Gramps wiki rather than the GitHub wiki for documentation.

[Nick-Hall]

Nothing much to say at the moment. Obviously, each file will need a header containing program, copyright and license information.

The code should also conform to our programming guidelines and we should aim for a pylint score of 9.0 or higher. However, don't feel that every file must have a score greater than 9.0 if it not sensible to do so, especially in small files.

[brylie]

Ok, I'll follow the developer guidelines from that document.

[brylie]

@Nick-Hall this PR is ready for review.

[Nick-Hall]

I'm not a django expert, but it looks good to me.

Please add a header to each file. I have committed a sample for you to copy.

A quick pylint also reveals a missing module docstring in the manage.py file. Some short like "A utility for administrative tasks" should suffice.

[brylie]

@Nick-Hall thanks for catching the lint and reminding me. What do you think about enabling PEP8 Speaks on this repository, to automatically check for code lint in pull requests?

[brylie]

@Nick-Hall I resolved the lint errors and added a license notice to all project Python files. Please review.

[Nick-Hall]

@brylie We usually place the copyright and license at the start of each file as recommended in the license file.

Using PEP8 Speaks is a good idea. I'll look into it. Maybe we can use it for core Gramps as well.

[brylie]

For whatever reason, PyCharm puts the license notice after module docstring and #! line, if present. I don't really want to fight the IDE on this one, and noted that it is not a strict requirement that a Copyright notice begin on line one.

I will look for a setting in PyCharm ASAP, as I am currently on my phone.

[Nick-Hall]

One of our developers applied for a PyCharm license back in 2011. What is it like?

As far as I know, the shebang and/or encoding lines need to be before the license at the top of the file. The module docstring can be below it, and this is where we place it in the Gramps code. Let me know if this causes a problem.

[brylie]

Overall, PyCharm provides a really nice developer experience, including Django helpers and debugging. I have spent the past several years doing JavaScript development and debugging without basic things like 'go to definition', debugging breakpoints, intelligent code completion, etc., so PyCharm feels like a whole different level of support.

I would like that there were an open-source IDE, perhaps built in Python, with rich Django support, but haven't found one.

[brylie]

I have searched around and read the PyCharm documentation, but can't find any solutions for specifying that the Copyright notice be added above the module docstring. I opened a question on StackOverflow in this regard.

If there doesn't emerge a simple, automated solution to handle this, I respectfully request that we overlook this issue, so that we can move forward with development.

[Nick-Hall]

@brylie Is this ready to merge? Do you want to squash the commits?