I'm using the django registration app in my django site. And now I want to add more custom code. I think it would be better if I can modify directly to the original code of the django registration app.
How can I do that?
Should I just download the source code of the django registration app and then put into my project folder. From my understanding, it will check the files right under my project folder first before checking similar files under DJANGO_HOME\contrib.
Is it right?
Ideally, you should not modify the source unless you want to push the changes back to the original source.
Just create a new app and extend/override/copy whatever methods that are custom for your project.
The reason for this is that if django-registration updates their code, you're gonna run into maintenance overhead. If it's separate, you can still update it with pip (you are using virtualenv right?), and then all you need to change are your custom methods and classes.
Yes, you can simply place it in your project folder, and modify it to work as you wish. You can also remove the installed one since you will no longer need it in this case.
Do remember to included it in your INSTALLED_APPS in your settings file.
Disclaimer: generally, it is considered bad to edit source code of installed apps. Another application on the same host would not be aware of your changes (btw, take a look at virtualenv). You can forget you've changed somehting and get unexpected behavior. You will not track changes. Ie, it's too easy to break something. If you want to change an existing app, copy it to your project dir and then change.
From your other question, it looks you're asking about django-registration from ubernostrum. This app supports custom backends and events that would be probably enough for you.
Related
I'm making a Django project consisting of several apps and I want to use a version number for the whole project, which would be useful for tracking the status of the project between each time it comes to production.
I've read and googled and I've found how to put a version number for each django app of mine, but not for a whole project.
I assume that the settings.py (in my case it would be base.py, because the settings are inherited for each environment: developmente, pre-production, production) would be the ideal file for storing it, but I would like to know good practices from other Django programmers, because I haven't found any.
Thank you in advance
I don't think I've ever needed to do this, but the two obvious choices would be either the settings file, as you state, or alternatively the __init__.py in the main project app.
You don't need it to relate to django, you can tag a commit in your source control to provide a marker of a particular version (as well as a separate branch for releases).
From the docs for git tagging
Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on).
You could use the same versioning number system as google if you so wish which relates to
year.month.day.optional_revision # i.e 2016.05.03 for today
Doing this would make it easier to track back to previous versions since it won't be overwritten in source code by newer version numbers.
I like to deploy the Spreecommerce locally and want to implement my own changes. I have deployed successfully but I don't know where the actual sources files comes or running. I need help to sort this out. Please can any one help me.
Thanks in Advance
Bundler downloads dependent gems into a cache location, but you don't want to mess with that if you're looking to make code changes. Anything you change there will be lost later when you update your gems.
You'll want to familiarize yourself with the standard rails customization methods. In order of least-to-most intrusive:
Decorators - files in your host application's app folder structure (assets, controllers, models, overrides, views, etc) which change a single method on Spree's objects by using the syntax Spree::[whatever class].class_eval do and then using standard ruby method definitions (followed by end). These files match their Spree counterpart in the same folder, just in your app instead of Spree's source. And with _decorator added to the end of the filename. See an example here: https://github.com/binaryphile/spree_dibs_1.2/blob/master/app/controllers/spree/admin/payments_controller_decorator.rb
Overriding entire Spree files - copy the Spree source file to the same location in your app then make the necessary source changes. This will override Spree's file of the same name (no _decorator this time). You're taking responsibility for migrating all future code changes by Spree to that file into your copy, which is why this is less desirable.
Fork the Spree source - change your Gemfile reference to your version instead of Spree. Make your changes to this code directly and run it instead of regular Spree. This is highly undesirable, as it makes upgrading Spree versions very involved and difficult.
If you're planning on making the code reusable, you could also investigate making it into an internal or published extension. See the Spree docs on that approach.
I would like to install a djangopypi server for our local development and deployment. However, I'm slightly confused about its installation docs. Apparently, it's assumed that djangopypi is installed inside a bigger project as an app, which is at least debatable from my point of view. I would like my local PyPI instance to run independently of anything else, as a "normal" web service.
And this is where I'm lost. It seems I need some kind of a minimal Django project to wrap djangopypi, which seems a bit overkill for me. Is there a more elegant way to install it in standalone mode?
That's exactly what you need. djangopypi is just an app. Like any Django app, it needs to know stuff like how to connect to your database, etc. That information comes from the project. It doesn't provide this for you because there's no way it could possible know what the best settings are for your particular environment; that's your responsibility.
So, no, it's not "overkill". It's the bare minimum required for functionality, and it's just the way things are. Create a simple project, change all the relevant items in settings.py, nclude djangopypi's urls.py in yours, and you're done. Is is really that hard?
I've just started using Django and one thing I find that I'm doing is starting a lot of new projects. I'm finding this process to be pretty tedious every time, even using manage.py startproject * I'm constantly changing settings in settings.py like media_root and template paths. Just a little background, I come from PHP and CodeIgniter. I never used a stock CI directory. I modified it to meet my needs for a new project. When I needed a new project, I would just copy that directory. manage.py seems to generate the files on the fly so this approach doesn't seem that possible. Does anyone else have any advice on this?
Lincoln loop has some best practices, they suggest importing settings from a different file. http://lincolnloop.com/django-best-practices/projects/modules/settings.html
Also checkout pip requirements, you might be able to use this to install the settings module from an external source like a git repo.
I'm using Paver to automate my Django project setup.
I have a Bitbucket repository with my own bootstrap setup. Eventually I'll make this generic, but for now it might give you some example code
Sounds like you're starting new projects very often. I assume that's because you're learning. Sure, if there's a custom settings.py that will save you some typing as you generate your learning projects, create it and use it. You could make your template the whole project directory, but since you're unlikely to have a lot of project-level boilerplate outside of settings.py, just focus on that one file. The settings file is the essence of the project.
Django development is all about apps. As you learn more, apps will start to become your focus. My advice would be not to pour too much energy into making an efficient assembly line for project creation.
Also, please learn and use use version control. For bonus points, also learn and use virtualenv :)
I'm updating a 0.5.1 complete_project to 0.7beta3 + virtualenv + pip + fabric.
I have converted my project into multiple stand-alone applications and I have everything being pulled down by pip from a requirements.txt file.
I am now moving the code over and so far can get the Welcome page and perform a log-in, but then it breaks, due, it appears, to the introduction of Group support and the refactoring of Tribes into Tribes and Topics.
Has anyone successfully made this move? If you did, how did you handle migrating your data? What should I be looking out for? Anyone have a checklist or list of steps? What other exciting challenges do I have to look forward to?
The short answer as far as I'm aware (and I've been following Pinax development for some time now) is that there is no straightforward path to upgrade the project from 0.5.1 to 0.7beta3. I'm not sure how familiar you are with the code, but this is the process I would use based on my limited experience:
Start by using the social_project/ that ships with the latest version of Pinax. Copy into it any changes you made to the settings.py file as well as any custom apps you have.
The templates and media have moved to folders outside of the projects, but if you customized any of them (I'm sure you did) take the custom ones and drop them into the template folders in your project to override those in the default theme folders. You should compare them to those in the theme folders to see what changes may need to be made to keep up with changes in the apps.
The next step would be to do the same thing with urls.py copying any customizations over the one provided by the project.
Try getting it running at this point with a fresh DB. Hopefully any errors will point you in the right direction to stuff that you might have missed or not known about.
Once you gotten it running most of the DB tables should be the same (I believe) except as you mentioned the Tribes stuff. Migrating the data, though, is still beyond what I've had to deal with.
Disclaimer: I've been following development but never had to perform an upgrade quite this big. Good luck and (obviously) back up your work and data before trying to port it all over.
See the documentation and code ( http://github.com/pinax/pinax/tree/master ) for more details. The code is a convenient (though tedious) way to watch the evolution between 0.5.1 and 0.7beta3, for what that's worth.