Newbie Django Mac OS X suggestions.
Sector7B
running in Mac OS X after about a day or two of frustration.
Step 1: Abandon all Apple supplied tools, and switch to using macports
for everything. I could be missing something and someone could say
they had no problems and if so good for them. But once I moved all my
development using macports everything just worked.
Roughly from memory:
Step 2: Install macports www.macports.org
Step 3: In system preferences turn off Web Sharing.
Step 4: sudo port install python
Step 5: sudo mv /usr/bin/python /usr/bin/python.ORIG
Step 6: cd /usr/local/bin;sudo ln -s /opt/local/bin/python2.6 python
(i made an alias in bash_profile, but sudo won't use it, so i
symlinked it.)
python -c "from distutils.sysconfig import get_python_lib; print
get_python_lib()" should tell you something like: /opt/local/Library/
Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
(notice: "/opt/local", this tells you its working. This is useful
when setting up django.wsgi)
Step 7: sudo port install apache2
Step 8: (mysql) sudo port install mysql5 mysql5-server py26-mysql |
(postgres) sudo port install postgresql84 postgresql84-doc
postgresql84-server py26-psycopg2 (install pgadminIII from here:
http://www.downloadplex.com/Mac/Business/Databases-amp-Tools/pgadmin3-for-mac_222082.html)
Not an expert at postgresql! There might be a better download site or
version.
Step 9: download and install django, read read read.
Step 10: victory!
Hope this helps someone in the future. Feel free to add anything I
missed.
-j
Dave Murphy
> Hi, I thought I would share some insight into getting django up and
> running in Mac OS X after about a day or two of frustration.
>
> Step 1: Abandon all Apple supplied tools, and switch to using macports
> for everything. I could be missing something and someone could say
> they had no problems and if so good for them. But once I moved all my
> development using macports everything just worked.
Disagree almost completely. I'm happily developing Django using the
Apple supplied Python and tools, although I have complemented them
with virtualenv and pip.
The only sore spot in my development stack is that I can't get
psycopg2 to work (due to issues with 32/64-bit in SL), but I simply
work around that by using SQLite in development and PostgreSQL in
staging/production. Don't use MySQL, so can't comment on that.
Oh, and just because anecdotal experience is complete subjective, I've
had nothing but hassle from using the likes of Macports and Fink so I
wouldn't recommend them to anyone.
Shawn Milochik
In addition, I have the solution to your problem with psycopg2:
http://shawnmilo.blogspot.com/2009/11/psycopg2-on-snow-leopard.html
Dave Murphy
> In addition, I have the solution to your problem with psycopg2:
> http://shawnmilo.blogspot.com/2009/11/psycopg2-on-snow-leopard.html
Thanks Shawn! I'll try that one out. I'd already tried all the other
suggestions I could find, but hadn't seen that one.
Shawn Milochik
Let me know if you have problems. As much as I love sqlite3, I depend on South, and sqlite3 doesn't support some functionality, including deleting columns.
In addition, I learned another cool trick since that blog post, which was replacing 'make && make install' with 'make && make altinstall,' which is really sweet. It compiles and installs Python (in an alternate directory) and leaves your currently-installed Python installation alone. The beauty of that is that you don't take the chance of breaking anything else on the system. Not really an issue with Snow Leopard, which comes with 2.6, but it was a lifesaver on my production CentOS server, which uses 2.4 for some of the system functionality.
Shawn
Graham Dumpleton
On Jan 31, 4:11 pm, Dave Murphy <d...@schwuk.com> wrote:
I'd agree, from the perspective of dealing with mod_wsgi questions all
the time, both MacPorts and fink distributions are a PITA.
The Python distributions from MacPorts especially don't seem to be
built properly and give lots of problems when being embedded in
systems such as mod_wsgi due to runtime framework linkage not working
properly. The MacPorts and fink distributions in the past, not sure
about now, were never properly compiled as fat architecture binaries,
which always gave problems with Apache supplied with MacOS X which
will run in 64 bit mode by default.
So, OP may have not have problems, but that is because MacPorts may
work with itself, but as soon as you try and use it with anything else
or want to run stuff as 64 bit you more often than not get problems.
Graham
Thomas Schreiber
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Nick Lo
> Apple supplied Python and tools, although I have complemented them
> with virtualenv and pip.
>
> The only sore spot in my development stack is that I can't get
> psycopg2 to work (due to issues with 32/64-bit in SL), but I simply
> work around that by using SQLite in development and PostgreSQL in
> staging/production. Don't use MySQL, so can't comment on that.
I think Python/MySQL was actually easier to setup on Snow Leopard than leopard. Either way, I'm another that agrees with you Dave. I've found that keeping as close to the Apple supplied tools usually works out easier in the long run. Particularly with regards to OS updates etc.
Nick
Graham Dumpleton
On Jan 31, 6:40 pm, Thomas Schreiber <t...@insatsu.us> wrote:
> I am extremely satisfied with Homebrew for OSX packet management:http://github.com/mxcl/homebrew
>
> Much cleaner to customize and get right than macports, fink, or manual
> building. New recipes get added all the time, and most everything I've
> needed is already there.
>
> With home brew I never touch anything in System python, and I simply use it
> to install 2.6.4 as my main python.
> I run easy_install pip, pip install virtualenv and using virtualenvwrapper,
> install any other packages into project relevant virtualenvs, always
> creating with --no-site packages.
But did you ever try using mod_wsgi?
From problems some have had in using homebrew with mod_wsgi, it seems
worse than MacPorts and fink when it comes playing nice with embedded
systems. The default installation of Python in homebrew appears not to
even supply a dynamic Python library or framework that can be linked
in an embedded system.
Graham
> On Sat, Jan 30, 2010 at 22:55, Graham Dumpleton
> <graham.dumple...@gmail.com>wrote:
> > django-users...@googlegroups.com<django-users%2Bunsubscribe@google groups.com>
dk
with my own.
Ignoring a bit of time with VMS, I have been a *nix user since the
1980s. My path has been from BSD to solaris to linux to osx. A
pleasure in moving from solaris to linux, was the tools for bulding/
install software. Rpm, yum, apt-get, etc. are very handy when you
just want to get things done and are really not interested in patching
code, or applying patches of questionable provenance.
When I switched to OSX, I thought it would be great to have build/
install tool, and so Fink and Macports were both attractive to me. I
started with Fink, but something (that I don't recall) annoyed me, so
I switched to Macports. After a while, though, it too started to wear
thin.
1. Some things were not ported yet.
2. Some ports were not up-to-date. [Confession: I had ported one of
my own packages (see gri.sf.net) and I didn't even keep that up to
date, partly because it was tiresome having to adjust to slight
changes in the port driver files.]
3. Macports suffers a bit of "dependency hell", as the linux people
call it. An update to one package can necessitate updates to many
more packages. (I've done "port" commands that took many hours, just
to update something trivial.)
4. The apple-supplied utilities (compilers and such) are now much more
up to date, so there's no need to use macports to get something
recent.
5. A lot of applications (gui-based software) have been ported
directly to the OSX environment, and are available as self-contained
packages.
Given all of this, I didn't even bother installing macports on the OSX
machines I bought in 2009. There seemed to be no need at the time.
And, months in, I've not felt any need to install it. On those rare
occasions when software was not pre-built, I just built it the old-
fashioned way, with ./configure and make. Very rarely, a patch might
have to be applied, but I'd rather see such things explained on blogs
than trust a patch supplied in a port file.