Code

Opened 5 years ago

Closed 21 months ago

Last modified 21 months ago

#10936 closed Cleanup/optimization (fixed)

Detailed instructions for getting Django and MySQL and MySQLdb working on various OS X versions

Reported by: simon Owned by: nobody
Component: Documentation Version: master
Severity: Normal Keywords: mysqldb
Cc: timograham@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Getting MySQLdb working on OS X is an absolute nightmare, which has resulted in a flurry of blog posts such as the following:

http://www.keningle.com/?p=11

This really shouldn't be our problem since it's not a Django issue - but OS X / MySQL are an extremely common development platform for our user base and it makes a really bad impression if people can't get up and running with this (especially since PHP + MySQL on OS X works pretty much out of the box). I just had to talk someone through this over the phone and it was a bit embarrassing having to admit how miserable the MySQL / OS X installation experience for Django actually is.

We could do this as part of a larger project to bulk out our installation instructions for other platforms as well.

Attachments (1)

10936.diff (1.2 KB) - added by timo 21 months ago.
updated per Karen's feedback

Download all attachments as: .zip

Change History (19)

comment:1 Changed 5 years ago by kmike

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

It was quite easy for me to install python & mysqldb on OS X Leopard using macports, all works fine out of the box.

comment:2 Changed 5 years ago by Alex

  • Triage Stage changed from Unreviewed to Design decision needed

We've been moving a way from keeping detailed platform specific installation docs in our own docs and instead moved them to the wiki. Perhaps the best solution is for someone to put this information on that wiki page and make sure the link is prominently displayed in the docs.

comment:3 Changed 5 years ago by simon

I'd really like to avoid having MacPorts as a dependency for getting a basic Django setup running on OS X!

Maintaining this stuff on the wiki seems reasonable. I'll have a go at reorganising the installation docs on the wiki a bit and filling in some holes.

comment:5 Changed 5 years ago by adamnelson

Actually, when I was new to Django, I didn't know a few things:

  1. The Django community does in fact favor PostgreSQL. It might be good to simply make that clear to first-time users that PostgreSQL is the most common DB used on Django production environments.MySQL is fine (I use it over PostgreSQL) but here's the important part ...
  2. Developers should typically use Sqlite3 and neither Postgres or MySQL except for QA and live environments. It's a much more portable/simple database backend for development and it works on Mac out of the box.

I went through a whole bunch of shenanigans to get MySQL running on Mac only to realize that I would never run my project on anything but Linux anyway and that with the ORM, Sqlite3 is fine for development purposes.

So, I think this ticket should be sidestepped with a clear declaration that PostgreSQL is the most test db backend and that development is easiest with Sqlite3 as the backend - the ORM abstracting most differences away.

comment:6 Changed 5 years ago by mtredinnick

Both of the assertions in comment:5 aren't correct. MySQL is tested at least as much as PostgreSQL, arguably has more code in Django to support it and is quite possibly even used more in terms of raw numbers, since it's the default with a bunch of hosting accounts. Also, developing against a database other than SQLite3 is often a good idea. Even necessary if you're using some of the database-specific features, such as postgis or text-field searching (MySQL) or stored procedures (vary per database), etc.

I feel this whole ticket is probably a bit out-of-scope, since being a sysadmin for your box isn't really a goal of Django. Some pointers to links to help people do that setup or, as noted elsewhere, a wiki page maintained by people who actually do this and need it would probably be more efficient and accurate.

comment:7 follow-up: Changed 5 years ago by adamnelson

Anyway, at least a strong statement on the wiki telling people that, unlike PHP/Perl (where most future Django people will be coming from, i.e. the audience for this wiki page), that Sqlite3 really is the way to go for desktop development.

Not one person I've introduced to Django knew that on their own. Each one struggled to install MySQL and MySQLdb on their Mac (since that's about what they would have done for PHP) before I told them it's a waste of time and they should just use Sqlite3 which works by default.

That isn't clear from the docs and I'm confident that many people are trying in vain to install MySQL and associated libraries for only minimal benefit.

comment:8 in reply to: ↑ 7 Changed 5 years ago by sampablokuper

Replying to adamnelson:

Anyway, at least a strong statement on the wiki telling people that, unlike PHP/Perl (where most future Django people will be coming from, i.e. the audience for this wiki page), that Sqlite3 really is the way to go for desktop development.

Not one person I've introduced to Django knew that on their own. Each one struggled to install MySQL and MySQLdb on their Mac (since that's about what they would have done for PHP) before I told them it's a waste of time and they should just use Sqlite3 which works by default.

That isn't clear from the docs and I'm confident that many people are trying in vain to install MySQL and associated libraries for only minimal benefit.

+1

I'm one of those people, and I've just been spending a fair chunk of my afternoon setting up MySQLdb on a Mac. Previously, I've only done Django development on Windows, where MySQLdb is much more straightforward to set up. Since my production environment uses MySQL, I prefer to use it for my development environment too, both so that I can feel more confident about deployment, and so that I don't *have* to get to know another SQL RDBMS (e.g. Sqlite3).

comment:9 Changed 4 years ago by gabrielhurley

  • Triage Stage changed from Design decision needed to Accepted

After reading the various comments and doing a bit of discussion, I've got three actionable recommendations here:

  1. Add a note to the quick install docs and the topics/installation docs that notes something along these lines: "It is a very common practice to use sqlite3 in a desktop development environment. Unless you need database feature-parity between your desktop development environment and your deployment environment, using sqlite3 for development is generally a much simpler option."
  1. Add a link to the Distributions wiki page from the installation docs that says something like "Further installation guides may be available on the Distributions page in the wiki."
  1. Add any relevant information regarding Django/MySQL installation and setup on Mac OS X (as requested by this ticket) to the wiki.

comment:10 Changed 3 years ago by julien

  • Severity set to Normal
  • Type set to Cleanup/optimization

comment:11 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:12 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:13 Changed 21 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 470deb5cbb765e2e731c5b0b184247c7f87482aa:

Fixed #10936 - Noted that using SQLite for development is a good idea

comment:14 Changed 21 months ago by Tim Graham <timograham@…>

In 8139a7990a682f282096167bcea35004cacf5559:

[1.4.X] Fixed #10936 - Noted that using SQLite for development is a good idea

Backport of 470deb5cbb from master

comment:15 Changed 21 months ago by kmtracey

  • Resolution fixed deleted
  • Status changed from closed to reopened

I do not agree that using SQLite for development is a good idea, in fact I think it is a spectacularly bad idea. SQLite will let pass many things which will be caught as errors by the other backends. This is setting people off for a very bad experience of moving code to production for an easier start, I do not think that is a good trade. I think this recommendation should be reverted.

Version 0, edited 21 months ago by kmtracey (next)

Changed 21 months ago by timo

updated per Karen's feedback

comment:16 Changed 21 months ago by timo

  • Cc timograham@… added
  • Has patch set

Thanks for the feedback Karen. I agree and didn't mean to give SQLite such a ringing endorsement. I've added an amended patch per your comments.

comment:17 Changed 21 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from reopened to closed

In 9190d89829c4e0b9b0f36e1c717ea451a1a13efd:

Fixed #10936 - Tempered recommendation of SQLite - thanks Karen Tracey for the feedback.

comment:18 Changed 21 months ago by Tim Graham <timograham@…>

In 81020708eae0a38b56cad86a043a78ffac9ba32a:

[1.4.X] Fixed #10936 - Tempered recommendation of SQLite - thanks Karen Tracey for the feedback.

Backport of 9190d89829 from master

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.