51–60 of 65 posts
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.
Be wary of using case sensitive FS. Many apps simply don't work on case sensitive. Maybe they've fixed it, but not long ago the whole Adobe suite just wouldn't work on case sensitive EXT FS. You should use a convention for your filenames anyway. Eg in Python you always use lower case.
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.
We've had a couple hiccups going from Mac to Linux because of this (if you call a folder 'Assets' and there's already one called 'assets', you're going to get two distinct folders on your Linux server and scratch your head for a while until you figure out why something didn't change), but you mostly don't have to worry too much about it.
Earlier quoted context omitted.
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.)
Earlier quoted context omitted.
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.
I had tons of issues trying to get Postgres to work on my Mac. Lots of other conflicts, too. I think the Mountain Lion OS upgrade fried my host dev environment, too. Eventually, I went the VM route....afterall, you're going to eventually deploy to a Linux box anyway, and there's enough differences that you'll feel the pain when you go to deploy. And now, I don't have a polluted host OS with tons of versions of softwa…
RAM was cheap. Prices have went up a lot. Most DDR3 prices have almost doubled since this past spring/winter. 16GB laptop kits are ~ $140 when they were $75 a few months back. Still relatively cheap, though.
Not to mention Apple only makes 1 laptop that you can add your own RAM to nowadays (13" MBP). It's $200 to go up to 16GB on a Retina.
Earlier quoted context omitted.
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 p…
Having used Homebrew now for many years, this is really just lingering FUD from many years ago. I've spent at least as much time building custom RPM/DEB packages, finding PPAs, etc. for things which don't compile cleanly on a particular Linux distribution. That's just a cost of using bleeding-edge or obscure packages: the right lesson to draw is to avoid taking on the cost of using less stable packages unless you gain significant benefit.
> Vagrant boxes also are platform independent if he had a vagrant development env, he wouldn't have to blog about how to install python
He didn't — that's a local cost he chose to take on for perceived benefits but it's neither necessary not advisable if you don't need something other than the system installed Python (2.5-2.7). This is exactly the same situation as on a Linux distribution.
> 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.
This is a platform-neutral problem which has been well solved for many years using Virtualenv:
> All in all: It's cleaner, less work and more flexible.
What you described is a LOT more work and adds significant performance and usability overhead to things you do many times a day, particularly if you need to work on more than one project and spend time spinning Vagrant instances up and down, installing updates, etc. rather than doing something productive.
It might still be worth it if you really need to test your deployment process all the time but otherwise that cost adds up. Personally, running locally and testing on EC2 has been much easier, faster, and makes my testing realistic by using the actual real production infrastructure rather than a facsimile crammed onto one laptop.
Earlier quoted context omitted.
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.)
Yeah, I'm thinking about going down the VM route with Ubuntu Server inside Parallels. Seems a bit of a waste of computing resources though.
EDIT: and in terms of resource usage, RAM is cheaper than headaches.
Earlier quoted context omitted.
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 p…
> 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 Having used Homebrew now for many years, this is really just lingering FUD from many years ago. I've spent at least as much time building custom RPM/DEB packages, finding PPAs, etc. for things which don't compile cleanly on a particular Linux distribution. That's just a cost of using…
Actually, I can cite an example. Try installing libmediainfo on your mac. It's a pita that requires hacking the makefiles in obscure ways. Even after hacking the makefile it installs in different locations than on linux, making all software that depends on it more difficult to compile. Oh, and yes, there's a gui package but it doesn't contain the required library files and headers.
Homebrew is fine for everything that homebrew packages exist for. Anything else you'd better hope that the authors provided a working makefile or be prepared to learn how to fix it.
> spend time spinning Vagrant instances up and down, installing updates, etc. rather than doing something productive.
I install updates when the target env installs updates. I share the puppet/chef files that are used to update the target env - so the maximum amount of time I spend doing unproductive things is typing "vagrant up" in the morning and "vagrant suspend" in the evening. Each one of those commands runs 30 seconds.
Since when does virtualenv install the actual pythons?
> Personally, running locally and testing on EC2 has been much easier
You're certainly aware that you can use packer and vagrant in combination to build the same box for virtualbox/vmware for local use and as an AMI for use in EC2, making your development env a clone of the production env? Just with faster connectivity and no need to be online for work? Vagrant can even spin that ec2 instance up and down for you.
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 com…
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 com…
wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py -O - | python