Live data from Hacker News

Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

builtbyptm.com

1–10 of 43 posts

Re: Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

#3
I have been a Django developer for a few years now. If you are like me and you start a lot of new Django projects, trust me when I say you do not have time NOT to use this. Awesome tool that helps you get up and running with an new Django project quickly. Go, now, quick...start using it.

Re: Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

#7
I wrote a tool (along similar ideas, starting out is always a needless time sink) called GluStik (punning Paster) https://github.com/leetrout/glustik#default-djangoglu-method...

Now GluStik scratched my itch of needing a very specific, custom layout, represented in code, and plopping in Django's files (like settings) so it provides hooks to use Django's templates. I'm curious what sort of design decisions went into project builder and what plans exist to support emerging trends?

For instance, I would much rather have a settings package with base.py and local.py inside where my local settings can extend base settings (like INSTALLED_APPS += ('debugtoolbar',) ala Brack3t's Modular Settings https://github.com/brack3t/django-modular-settings

I realize this isn't the default Django behavior but I know more than a couple developers that use this format. So if project builder is about "sane defaults" and the masses prefer this is there a plan to support it (or other, similar developer centric preferences that are outside the "Django way")?

Re: Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

#8
post #7

I wrote a tool (along similar ideas, starting out is always a needless time sink) called GluStik (punning Paster) https://github.com/leetrout/glustik#default-djangoglu-method... Now GluStik scratched my itch of needing a very specific, custom layout, represented in code, and plopping in Django's files (like settings) so it provides hooks to use Django's templates. I'm curious what sort of design decisions went into p…

We have included settings_local.py for development purposes, which gets imported by settings.py if it can be found. The main purpose for this is for the settings_local.py to be using sqlite3 rather than postgres, which is the default in settings.py.

Another thing which is kind of hidden is the ptm1.4 branch. This is a branch that includes a lot more, and will be growing quickly. We wanted the master branch to be generic as possible, and have it so people can easily switch out our defaults for their own, i.e. changing any of the files in django-files/ for their specific needs.

In regards to supporting other 'preferred practices', we welcome people to fork this repo and contribute stuff back. The master branch will be staying more generic, but we are all for best practices no matter if they are the "Django way".

Re: Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

#9
The quality of this leaves a lot to be desired* and you would be better off with using a 1.4 project from somewhere like https://github.com/xenith/django-base-template.

*Hardcoded ubuntu user and hardcoded py26 and py26 paths in different files: https://github.com/prototypemagic/django-projectbuilder/blob... https://github.com/prototypemagic/django-projectbuilder/blob...

Re: Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

#10
post #9

The quality of this leaves a lot to be desired* and you would be better off with using a 1.4 project from somewhere like https://github.com/xenith/django-base-template . *Hardcoded ubuntu user and hardcoded py26 and py26 paths in different files: https://github.com/prototypemagic/django-projectbuilder/blob... https://github.com/prototypemagic/django-projectbuilder/blob...

Even though it doesn't seem to be the case when viewing the README, this is more for automatically creating a Django app rather than the deployment process. There are things like Chef, or even Fabric, which are far more swag for auto-deployment.

The core aspect of this is the Django defaults and the front-end stuff. The server scripts are in a separate folder for a reason.

Post reply on HN