Live data from Hacker News

Installing and setting up OS X Mavericks for Python development

blog.kristian.io

41–50 of 65 posts

Re: Installing and setting up OS X Mavericks for Python development

#41
post #10

just use a vm (eg vagrant) or a remote server and be platform independent!

Why use extra RAM on Vagrant when your Mac OS X is a full-featured Unix OS? Don't get me wrong, I know that the more complicated your setup gets, the more it would make sense to use Vagrant - but if you're just developing a CRUD Flask / Django app with PostgreSQL, you might as well just install Postgres.app and develop locally.

Because even though OS X is a pretty full-featured unix not all software that installs easily on a linux installs easily on a mac os. Vagrant boxes also are platform independent if he had a vagrant development env, he wouldn't have to blog about how to install python. You also can get closer to the target env - i.e. use the python you'll have on the target server etc. You certainly can install all pythons that your projects use side-by-side, but this quickly turns into a mess when you have multiple projects that deploy on different target systems, maybe with different sets of libraries etc. You can test/develop deployment scripts locally. All in all: It's cleaner, less work and more flexible. In general the extra ram is not relevant now that the upgrade from 8G to 16G costs a mere 200 EUR.

Re: Installing and setting up OS X Mavericks for Python development

#42
This article is so opinionated. Just some counter-options:

Enabling apps from everywhere: Don't disable this. It's actually a good security feature. If you want to run an app that isn't signed, right-click and click "Open" and confirm you really want to run it and the OS will remember that choice for that app in future.

Terminal: The default Terminal is actually pretty solid. Much better than it used to be. Two common complaints (lack of tabs, lack of colours) are now moot.

Oh My ZSH: Or you could use fish – a new Mavericks compatible build (2.1) should be coming to the homebrew package manager literally any time now.

Also, for Python specifically (i.e. the title of this post), you can install a new version of Python via homebrew (and then place /usr/local/bin above /usr/bin in your PATH). This has the advantage of being able to run pip without superuser privileges. Though if you're using virtualenvs, it's probably not that big a deal anyway.

Re: Installing and setting up OS X Mavericks for Python development

#43

Earlier quoted context omitted.

Yes and no. Having done professional and personal development for OS X and two linux distributions (Fedora / Gentoo) it is most definately easier on Linux if you want to just hack together some software for your own use. As soon as you want to distribute that software however, the advantage often disappears - you can't use the package manager version of a lib because you need a feature in a later version, or because…

I'm a long-time macports user, and brew just blew me away with how much less work it made me do! (even just in terms of other source builds finding libraries by themselves - a real boon.)

I'd really like to use both macports and homebrew, and switch between them as necessary, but I don't know a good way of doing this. I know homebrew is relatively well-behaved and doesn't really put stuff outside /usr/local, but other things install into /usr/local too so I can't just remove that from my PATH when I want to use macports.

If anyone knows a reliable and simple way to do this I'd be very grateful.

Re: Installing and setting up OS X Mavericks for Python development

#44
post #7

From the post: "Homebrew helps you compile different kinds of software on your mac, making it feel almost as easy as apt-get'ing a package on e.g. ubuntu. " (emphasis added) This is something I've noticed from using both OSX and Linux for the past few years — unless software is available as a drop-and-install package, it's universally _easier_ to install in Linux* than it is in OSX. Given the market for OSX and the a…

it's universally _easier_ to install in Linux than it is in OSX* Unless the package is not in the repositories or you want to have an instance with some different flags. One of the really nice things of Homebrew is that besides being a package manager, it is a great /usr/local manager. For instance, installing something that is not in Homebrew is as simple as setting the prefix to /usr/local/Cellar/whatever/version a…

Or it simply has a name you don't expect. A lot of the problems I had in Linux, before I got used to it, was simply not knowing what I needed to install.

I'm used to being able to do, 'brew install foo' and not needing to worry if I needed libfoo, libfoo-dev, libfoo3-dev or just plain foo.

Re: Installing and setting up OS X Mavericks for Python development

#45

Earlier quoted context omitted.

The major reason behind the switch is that I recently had to rename a file, that someone accidentally comitted with an uppercase letter. We had to do it on another machine. It's a valid concern though.

Well, you can just use a mounted disk image formatted with a case sensitive HFS as development env. You'll need to mount that every time you restart but that's a minor hassle compared to problems you might run into when using a case sensitive FS for your primary partition.

So far - for development - I haven't had any issues with the case sensitive file system. I guess it's because in the end of the day, it's all tools made to work on Linux I use.

If you're using OS X for an all-round machine, it might be the wrong choice.

Re: Installing and setting up OS X Mavericks for Python development

#46

Earlier quoted context omitted.

Well, you can just use a mounted disk image formatted with a case sensitive HFS as development env. You'll need to mount that every time you restart but that's a minor hassle compared to problems you might run into when using a case sensitive FS for your primary partition.

So far - for development - I haven't had any issues with the case sensitive file system. I guess it's because in the end of the day, it's all tools made to work on Linux I use. If you're using OS X for an all-round machine, it might be the wrong choice.

Apple themselves used to discourage using a case sensitive partition for the OS. It's probably fine, just not the standard and widely tested configuration. The major hassle starts when one single program you need fails because of the setting - you'd just have to reinstall everything. So the safer way is use case insensitive for the primary and have a dedicated space for development with a case sensitive FS.

Re: Installing and setting up OS X Mavericks for Python development

#47
post #27

Earlier quoted context omitted.

If you develop your own applications, that can get very annoying very fast...

It never asks for locally created applications. It's purely for things downloaded over the Internet. In essence, it's a more advanced version of the original "You just downloaded this, are you sure you want to run it" warnings from the file quarantine system introduced with....Leopard, I think?

Yep, its asks it for files with the 'com.apple.quarantine' flag, which is attached to downloaded files.

You can see its value with:

  xattr -p com.apple.quarantine 
And remove it with:

  xattr -d com.apple.quarantine 

Binaries/application bundles that roll out of your linker/xcodebuild do not have that attribute. Hence, no bugging :).

Re: Installing and setting up OS X Mavericks for Python development

#48
post #44

Earlier quoted context omitted.

it's universally _easier_ to install in Linux than it is in OSX* Unless the package is not in the repositories or you want to have an instance with some different flags. One of the really nice things of Homebrew is that besides being a package manager, it is a great /usr/local manager. For instance, installing something that is not in Homebrew is as simple as setting the prefix to /usr/local/Cellar/whatever/version a…

Or it simply has a name you don't expect. A lot of the problems I had in Linux, before I got used to it, was simply not knowing what I needed to install. I'm used to being able to do, 'brew install foo' and not needing to worry if I needed libfoo, libfoo-dev, libfoo3-dev or just plain foo.

  apt-cache search foo
Done :). But I see your point. There's usually the library, the development headers plus static link library, and possibly some command line tools.

And usually the headers aren't that big (with the notable exception of template-heavy C++), so it's much simpler installing everything.

But such splitting primarily occurs in the Debian family.

Re: Installing and setting up OS X Mavericks for Python development

#49
post #43

Earlier quoted context omitted.

I'm a long-time macports user, and brew just blew me away with how much less work it made me do! (even just in terms of other source builds finding libraries by themselves - a real boon.)

I'd really like to use both macports and homebrew, and switch between them as necessary, but I don't know a good way of doing this. I know homebrew is relatively well-behaved and doesn't really put stuff outside /usr/local, but other things install into /usr/local too so I can't just remove that from my PATH when I want to use macports. If anyone knows a reliable and simple way to do this I'd be very grateful.

I'm not sure to what extent this works with brew, but you could try using virtualenv to manage different environments?

I've never had to deal with multiple configurations on the same mac (my solution, off hand, would be to use debian VMs, possibly through SSH rather than a desktop GUI if I needed >1 at a time.)

Re: Installing and setting up OS X Mavericks for Python development

#50
post #23

Earlier quoted context omitted.

Why is it even better?

Why yet another clone of powerline? vim-airline is a nice plugin, but it uses too much functions of other plugins, which should be done by users in .vimrc.

So it isn't strictly better just more standalone. I happen to use the other plugins already so I don't mind the dependency.

But I will try airline out. :)

Post reply on HN