Ultimately this is a fairly personal question, that will depend a lot on your workflow and preferences, but I'll add what I can.
My instinct is in line with yours—install the tools you need for writing your code natively, and use a VM for your server-side environment. My reasoning on this is that you (presumably) bought a Mac to use it, and doing most of your development work in a Linux VM seems like a bit of a waste. Use the native tools so that you can use them with whatever other OS X software you may want.
Similarly, while you could probably do a decent job of mimicking your deployment environment in OS X, using a VM is the best way to guarantee exact compatibility (it also makes it easier to manage different versions of your various programs, if you need to work with a production environment and a future server upgrade, etc.).
Ease of Use
I think the OS X tools + testing VM approach wins, as having all your development tools accessible without the need for a VM is the most frictionless, and the testing VM can act independently. OS X is BSD at the core, and as such there's great integration with the command line, particularly in developer-type tools like text editors.
Disk Space
VMs will obviously take up more room than just installing the tools natively, but Ubuntu seems to be able to run in a pretty small footprint (the CLI-only install on my home server runs around 3-4 GB I think, and that could probably be pared down if I tried). So unless you're really cramped for space, I wouldn't worry too much unless you need many different VMs.
Maintainability
I think you'll definitely want to go with a package manager, whether it's MacPorts or one of the other options. I'm not experienced with any of them, but I know MacPorts (and probably Homebrew and the others) have one line update commands, similar to apt
.
Currentness
This depends a lot on how you choose to install your software, and what software you're using. Apple tends not to update the CLI tools it bundles very often (often only with major OS releases), so if you rely on a particular version of something that's otherwise built in, you may want to install a newer version (which you should do by installing to a new location, not overwriting the system version). My best advice here is to do some Googling and figure out how current the packages that are important to you are in each package manager.
Performance
VM performance on any recent Mac should be pretty good, but it obviously depends on how intensive the tasks running on the guest OS are. Unless your server side component is pretty heavy (and I don't see why it would be under a development testing load), you should see pretty good performance, particularly if your VM doesn't run a GUI.
Anyway, that's my take, perhaps others can chime in with more specific opinions on Macports vs. other options, or other takes on VM vs. native.
The reason why Ubuntu works is that it has a package manager for all code, that is python and binaries. pip is a python installer and works in OSX for all pure python packages and simple C packages but seems to have issues with the more complex ones.
The nearest think to Linux's package managers are the package managers that deal with code ported from other Unices e.g. Macports, Homebrew, Fink. With choose one and one only as they can conflict (I use macports) and then use it for all possible ports.
In your case installing matplotlib would automatically install python, numpy, scipy etc
Best Answer
They can be used concurrently, and there should be no issue between mixing the two (with one kinda big caveat and a gotcha...)
The Caveat
The caveat is that macports/homebrew and pip will have no awareness of each has installed vs the other.
So, for example, lets say you install python 3.6 on your Mac. You want
nltk
, which is not technically available for that version on Macports, but it is on pip. So you install on pip. Two months later, you see its installed on Macports and choose to install it. Now you have two different versions ofnltk
on your machine, so caveat emptor.The Gotcha
If you do use pip with Macports, you need to make sure that it's the pip that is installed through Macports and associated with that python version. So, for example, you will see a py35-pip, py36-pip, etc.
Once you install the proper pip, you use Macports's
select
command to make sure that it's activated with the appropriate version of python: