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?
Related
I maintain an installable Django app that includes a regular test suite.
Naturally enough when project authors run manage.py test for their site, the tests for both their own apps and also any third party installed apps such as mine will all run.
The problem that I'm seeing is that in several different cases, the user's particular settings.py will contain configurations that cause my app's tests to fail.
A couple of examples:
Some of the tests need to check for returned error messages. These error messages use the internationalization framework, so if the site language is not english then these tests fail.
Some of the tests need to check for particular template output. If the site is using customized templates (which the app supports) then the tests will end up using their customized templates in preference to the defaults, and again the tests will fail.
I want to try to figure out a sensible approach to isolating the environment that my tests get run with in order to avoid this.
My plan at the moment is to have all my TestCase classes extend a base TestCase, which overrides the settings, and any other environment setup I may need to take care of.
My questions are:
Is this the best approach to app-level test-environment isolation? Is there an alternative I've missed?
It looks like I can only override a setting at a time, when ideally I'd probably like a completely clean configuration. Is there be a way to do this, and if not which are the main settings I need to make sure are set in order to have a basic clean setup?
I believe I'm correct in saying that overriding some settings such as INSTALLED_APPS may not actually affect the environment in the expected way due to implementation details, and global state issues. Is this correct? Which settings do I need to be aware of, and what globally cached environment information may not be affected as expected?
What other environment state other than settings might I need to ensure is clean?
More generally, I'd also be interested in any context regarding how much of an issue this is for other third party installable apps, or if there are any plans to further address any of this in core. I've seen conversation on IRC regarding similar issues with eg. some of Django's contrib apps running under unexpected settings configurations. I seem to also remember running into similar cases with both third party apps and django contrib apps a few times, so it feels like I'm not alone in facing these kind of problems, but it's not clear if there's a consensus on if this is something that needs more work or if the status quo is good enough.
Note that:
These are integration-level tests, so I want to address these environment issues at the global level.
I need to support Django 1.3, but can put in some compatibility wrappers so long as I'm not re-implementing massive amounts of Django code.
Obviously enough, since this is an installable app, I can't just specify my own DJANGO_SETTINGS_MODULE to be used for the tests.
A nice approach to isolation I've seen used by Jezdez is to have a submodule called my_app.tests which contains all the test code (example). This means that those tests are NOT run by default when someone installs your app, so they don't get random phantom test failures, but if they want to check that they haven't inadvertently broken something then it's as simple as adding myapp.tests to INSTALLED_APPS to get it to run.
Within the tests, you can do your best to ensure that the correct environment exists using override_settings (if this isn't in 1.4 then there's not that much code to it). Personally my feeling is that with integration type tests perhaps it doesn't matter if they fail. If you like, you can include a clean settings file (compressor.test_settings), which for a major project may be more appropriate.
An alternative is that you separate your tests out a bit - there are two separate bodies of tests for contrib.admin, those at django.contrib.admin.tests, and those at tests.regression_tests.contrib.admin (or some path like that). The ones to check public apis and core functionality (should) reside in the first, and anything likely to get broken by someone else's (reasonable) configuration resides in the second.
IMHO, the whole running external apps tests is totally broken. It certainly shouldn't happen by default (and there are discussions to that effect) and it shouldn't even be a thing - if someone's external app test suite is broken by my monkey patching (or whatever) I don't actually care - and I definitely don't want it to break the build of my site. That said, the above approaches allow those who disagree to run them fairly easily. Jezdez probably has as many major pluggable apps as anyone else, and even if there are some subtle issues with his approach at least there is consistency of behaviour.
Since you're releasing a reusable third-party application, I don't see any reason the developer using the application should be changing the code. If the code isn't changing, the developers shouldn't need to run your tests.
The best solution, IMO, is to have the tests sit outside of the installable package. When you install Django and run manage.py tests, you don't run the Django test suite, because you trust the version of Django you've installed is stable. This should be the same for developers using your third-party application.
If there are specific settings you want to ensure work your library, just write test cases that use those settings values.
Here's an example reusable django application that has the tests sit outside of the installed package:
https://github.com/Yipit/django-roughage/tree/master
It's a popular way to develop python modules as seen:
https://github.com/kennethreitz/requests
https://github.com/getsentry/sentry
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.
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.
For school, I have made a CMS in django for my major assessment task for Software. My teacher has asked to get the source code and, if applicable, the program compiled.
Now, because i dont want my teacher to install django (Something might go wrong, he may get a different version, missing dependences), how can i package up my django app, plus the django source and make the whole thing runnable (on the development server) by running a single script?
He has python, so that does not need to be included and the target OS would be OS X, but Windows can do as well.
Pip and VirtualENV will make this task much easier. (not sure the support for windows though)
PIP will help with the requirements installation.
http://pypi.python.org/pypi/pip
VirtualENV provides an isolated python environment.
URL: http://pypi.python.org/pypi/virtualenv
Reading through this blog post on installing Pinax will give you a good understanding on how the two work together: http://uswaretech.com/blog/2009/03/create-a-new-social-networking-site-in-few-hours-using-pinax-platform-django/
Perhaps Instant Django will set you in the right direction. It's for windows, but it might be of help.
Without having actually tested it, you should be able to copy the main django directory (/usr/lib/python2.6/site-packages/django for me) over into your project directory, and archive the whole thing. This will continue to keep everything importable (from django import ...), and make it so there's just one archive to extract.
Now, I wouldn't say this is a good way, but it's simple, and I think it'll work. I think.
I belive this is what your looking for (it's not pretty but it gets the job done).
It describes how to package django, a web server, and everything else needed to make a stand alone django application. To make it work for osx you should just be able to substitue py2app (http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html) instead of py2exe and it should (cross your fingers) work, however I have not tested it. Hope this helps!
Ps: sorry for not hyperlinking py2app im a new user and cant post 2 links yet :(