I developed a Django website in Linux, learning Django and git along the way; pushed the source files to Bitbucket.
I'm now in Windows and wanted to see if I could figure out how to work on the project from Windows (just to practice with version control). I did the following:
installed python (3.4) installed virtualenv,virtualenvwrapper-win
installed PostgreSQL from the windows installer on their website
installed psycopg2 from a .whl file because pip was insisting I don't
have c++
installed git using the windows installer from their website
cloned bitbucket repository using git
create a virtualenv using virtualenvwrapper, installed dependencies
from requirements.txt (except for psycopg2 which I had to install
manually)
now I'm a bit confused about the database, do I need to create a new one? how do I synchronize with the local database I created already in linux? is the database part of the version control?
I know that sqlite has a .sqlite file, but postgresql seems to work a bit differently.
EDIT:
I recreated the database and the user in windows, but how do I make sure the information with the Database synchronizes with wherever i'm developing
Fixtures can be used to move data between databases.
From the docs
A fixture is a collection of data that Django knows how to import into
a database. The most straightforward way of creating a fixture if
you’ve already got some data is to use the manage.py dumpdata
command.
--
Loading data is easy: just call manage.py loaddata <fixturename>,
where is the name of the fixture file you’ve created.
Each time you run loaddata, the data will be read from the fixture and
re-loaded into the database. Note this means that if you change one of
the rows created by a fixture and then run loaddata again, you’ll wipe
out any changes you’ve made.
Related
I'm new with python(don't know anything about it), and also in Django... so question is, what and how, step by step, I need to launch existing Django project which I got from github...
so, what I have done already:
installed python
created virtual environment
run python mange.py migrate, but it showed many errors(and I don't know what to do with it and how to fix them), because I can't even connect to DB(previously I worked with MySQL where I can connect by myself and do selects to check something in DB), but now this project uses SQLite3, and I don't know how I can check this database
run python manage.py runserver and I can see my webapp at localhost...
So, main question is, how to properly launch existing Django project?
I'm working on creating my first "real" web app using Django.
Yesterday I learned I should be using a web server like Nginx to serve static files and pass off requests for dynamic content to my web app. I also learned that I need something like Gunicorn as the intermediary between the web server (Nginx) and my Django app.
My question is about virtualenv. It makes sense that we would contain app related software in it's own separate environment. What should I install in virtualenv, and what gets installed system wide? For example, in this guide we seem to install Python, Nginx and the database system wide (because they're installed before virtualenv is installed) while Django and Gunicorn are installed in virtualenv. It makes sense that Gunicorn would have to go in the virtualenv since its importing our python app, as explained here. Are the other things required to be installed system wide? Or can I pick either way? Is one way preferred over another?
Thanks!
Virtualenv is for managing Python libraries. It is not for managing Python itself, or for external services such as databases; it does however manage the Python libraries you use to access the database.
There's no room for confusion here, because there's simply no way to install Python itself or a database within a virtualenv.
As a Django / Python newbie, should I try to debug on a server running 4 year old software versions, try to recreate the old software installations on my local, or just try to run the software in current version of Django/Python/Postgres/PostGIS on my local Mac OS X 10.9.5?
Background:
On a project where I was supposed to just load data into Postgres/PostGIS, I need to debug why a 2010 year old Django / Postgres / Postgis project is getting an error. I'm a LAMP developer who's never used Django or done much in Python, but I've been able to get a staging site working on the server, and make one or two changes. I thought it would make sense to debug locally on my Mac OS X 10.9.5. So I've used homebrew to install Django 1.7 and Postgres 9.3. Looking at the version differences, I'm worried it will be a more of a hassle now to try to migrate and upgrade the project than to attempt to debug it on the staging site instance running on the server.
FWIW, I know the lines of code that I'd like to investigate (seems like maybe an object is not getting loaded properly from db, since it is in the db), but I'm not positive what sort of echo statements to use. I like using IDE's to inspect things. The project is a bit of an orphan, as the first professional project of a developer who is no longer available to help. And of course, the deadline is last week. :(
Differences between your production and development environments can cause a myriad of headaches.
I recommend you use a tool such as Vagrant to set up a development environment running inside of a virtual machine that mirrors your production server.
Use VirtualEnv to emulate the necessary Django version. PostgreSQL is trickier, in theory you can have a second instance with the required version running simultaneously, but that can also cause very subtle conflicts. It would be better to have it running on another machine (virtual or physical) and access it through your local network.
The simplest way I think is to look at using unittest and mock object to set up some unit tests on the functions that you suspect are the cause of the problem. By using unittest and mock objects, you can control how the existing code interacts with Django and Postgres objects and allow for version differences by setting the expected return values.
With mock object, you can mock all or just part of an existing Python object, which reduces the dependencies you require for your development environment. Depending on how the code is structured, you might not need to install either Django or Postgres at all or a webserver for that matter. This blog explains Mock object in detail.
Even though you're pressed for time, you could do worse than setting up unittests for the whole project, future developers will thank you.
In terms of debugging, I personally can't reccomend pudb enough, it's an interactive command line debugger which you can use with unittest to zero in on what part of the code is causing the problem.
If you do need to install Django and Postgres, I would suggest looking at virtualenv which allows you to set up a virtual environment for Python. That way you can just install the specific dependencies you need without interfering with your global system wide installation. You can also install earlier versions of packages which would do the trick to emulate the existing system's state.
I've got a standard run of the mill Pylons Pyramid application, that uses SQLAlchemy for its database persistence.
I have set up an SQLAlchemy-migrate repo and have it functioning, but I really want to have the ability to use paster to upgrade and downgrade the database, or at least some way of having the user (after installing the egg) upgrade/downgrading the database to the version required.
I've got it built-into my app now, so upon app startup it does the version upgrade, but I would rather go with something where the user explicitly has to upgrade the database so that they know exactly what is going on, and know to make backups beforehand.
How would I go about that? How do I add commands to paste?
The way users would set up the application is:
paste make-config appname production.ini
paste setup-app production.ini#appname
To set it up the first time, to do the database upgrade or upgrade in general I would want:
paste upgrade-app production.ini#appname
Or something along those lines.
You can create your own paster command, e.g. upgrade-app, and then call it from anywhere with paster --plugin=appname upgrade-app /path/to/production.ini appname. You can refer to how pyramid implements the PShellCommand.
It's not quite what you're looking for, but one way I handle this is with Fabric commands. My OSS app I have a fabric command you run that creates a .ini file for your app and then, after you adjust the sqlalchemy.url in it, you run a fabric command that init's SA migrations and runs the upgrade. From then on, to upgrade you run fab db_upgrade.
http://bmark.us/install.html
is an example of the install docs I have setup.
https://github.com/mitechie/Bookie/blob/master/fabfile/database.py
Is the set of db specific commands available through the Fabric interface.
I am trying to create my first site in Django and as I'm looking for example apps out there to draw inspiration from, I constantly stumble upon a term called "reusable apps".
I understand the concept of an app that is reusable easy enough, but the means of reusing an app in Django are quite lost for me. Few questions that are bugging me in the whole business are:
What is the preferred way to re-use an existing Django app? Where do I put it and how do I reference it?
From what I understand, the recommendation is to put it on your "PYTHONPATH", but that breaks as soon as I need to deploy my app to a remote location that I have limited access to (e.g. on a hosting service).
So, if I develop my site on my local computer and intend to deploy it on an ISP where I only have ftp access, how do I re-use 3rd party Django apps so that if I deploy my site, the site keeps working (e.g. the only thing I can count on is that the service provider has Python 2.5 and Django 1.x installed)?
How do I organize my Django project so that I could easily deploy it along with all of the reusable apps I want to use?
In general, the only thing required to use a reusable app is to make sure it's on sys.path, so that you can import it from Python code. In most cases (if the author follows best practice), the reusable app tarball or bundle will contain a top-level directory with docs, a README, a setup.py, and then a subdirectory containing the actual app (see django-voting for an example; the app itself is in the "voting" subdirectory). This subdirectory is what needs to be placed in your Python path. Possible methods for doing that include:
running pip install appname, if the app has been uploaded to PyPI (these days most are)
installing the app with setup.py install (this has the same result as pip install appname, but requires that you first download and unpack the code yourself; pip will do that for you)
manually symlinking the code directory to your Python site-packages directory
using software like virtualenv to create a "virtual Python environment" that has its own site-packages directory, and then running setup.py install or pip install appname with that virtualenv active, or placing or symlinking the app in the virtualenv's site-packages (highly recommended over all the "global installation" options, if you value your future sanity)
placing the application in some directory where you intend to place various apps, and then adding that directory to the PYTHONPATH environment variable
You'll know you've got it in the right place if you can fire up a Python interpreter and "import voting" (for example) without getting an ImportError.
On a server where you have FTP access only, your only option is really the last one, and they have to set it up for you. If they claim to support Django they must provide some place where you can upload packages and they will be available for importing in Python. Without knowing details of your webhost, it's impossible to say how they structure that for you.
An old question, but here's what I do:
If you're using a version control system (VCS), I suggest putting all of the reusable apps and libraries (including django) that your software needs in the VCS. If you don't want to put them directly under your project root, you can modify settings.py to add their location to sys.path.
After that deployment is as simple as cloning or checking out the VCS repository to wherever you want to use it.
This has two added benefits:
Version mismatches; your software always uses the version that you tested it with, and not the version that was available at the time of deployment.
If multiple people work on the project, nobody else has to deal with installing the dependencies.
When it's time to update a component's version, update it in your VCS and then propagate the update to your deployments via it.