Hacker News Reader

Comment by sammcd | Hacker News Reader

After talking with a few small PHP teams this seems like the logical conclusion whenever growing a team of PHP developers. Its just very hard to perfectly recreate your server environment locally on multiple OS's.

Its a great solution, but I much prefer working with RoR or Python/Django where recreating the server environment locally is much easier.

View on HN

How is creating the local server environment on RoR or Python/Django easier than PHP/anything?

I've been developing locally for years and while I can't mimic the exact hardware of the live server, I wouldn't be able to do that regardless of stack I chose.

For the Python world, virtualenvs and pip requirement files make deploying a local copy of a project take about 30 seconds, and it's completely independent of your overall system and all other projects you happen to be working on.

Gotcha. With git and a Phing build script, I can do the same in PHP :)

As Pewpewarrows said, you can use pip with a virtualenv to deploy with one command. If your settings.py is any good, you can load your data dump in an sqlite database in one more command, and you're ready to go.

We used to develop historious like this, until we switched to redis/celery. Then it became too much hassle to install these in every machine, plus we wanted to test on the db we used (postgres) rather than sqlite, so we made a VM and now everything's dandy.

Bundler was supposed to remedy dependency hell problems and I believe it eventually managed to do that. But boy can I tell you stories about migrating from pre-1.0 bundler versions.

RVM is just great and simple.

What I’m trying to say though: Having done quite some side projects with node, the ruby stuff suddenly feels very enterprisey to me. More and more conventions might make it harder to keep track of everything in the future.

Your last sentence is an example of when I would like to vote "my displeasure" with a down arrow.

As others have mentioned, you make a bold claim, yet fail to give anything concrete as proof that it is "much easier".

even for RoR or python - might make sense for those working on multiple projects simultaneously, using different generations of frameworks

There's RVM in the Ruby world. Anything similar for Python?

virtualenv

I'd say that seems to cover both bases for not needing a VM.

Every language should have something as simple as these. Heck, it should be part of the OS, IMO; why I can't (easily) run two different versions of Firefox with two different profiles at the same time is beyond comprehension.

A VM is a constant time investment, doing it for every language is linear with the number of languages.

Unless there's some serious increases in clock speeds, I'm not sure doing it for every language is worth it. As it is, VMs are a great, general purpose system that are easy to set up, use, and replicate.

You do need a VM if you use memcached/redis/some other thing and don't want to install it on your machine. Other than that (for 90% of cases), virtualenv has you covered.

It's been a while since I've done this; but:

* Install your different Firefox versions in different locations (so one doesn't overwrite the other)

* Use "firefox -ProfileManager" to create at least one different 'profile', which is Firefox's user data set

* Use "firefox -P <profilename> -no-remote" to launch Firefox. -no-remote allows multiple Firefox instances to run on the same machine. -P profilename is necessary because you need a separate profile for each running instance.

More info at http://kb.mozillazine.org/Command_line_arguments

Ooh, I'll have to try that. I've been using different profiles, but didn't know about the last step.

Still; mindboggling. Different version = different binary launched, which accesses a different and non-locked profile. Why the hell does it instead open a new window of the currently-running version?

As a heads-up to anyone considering this: Sync doesn't (currently) like multiple versions. 3.6.10 won't sync now that I've hooked up some 4 betas.

Reply on news.ycombinator.com