IndigoStack

Love your rationale :) It is done. You may have to empty your browser cache if you want to see the change.

Exactly. I would argue this is the only way you can be sure your code will run properly in Production.

I found that when I tried developing inside a clone of my Production Docker environment, I started having to change more and more things over time eg installing Xdebug etc that meant it was not the reliable test environment I hoped it would be.

The binaries that ship with Indigo install their own shared libraries to /usr/local/Indigo. However there are a number of cases where they do still depend on macOS dylibs (stuff like libSystem, libiconv, libc++). In this case macOS updates won't ruin your setup, because Indigo will ship with binaries that specifically work with the new OS.

Re: 2) if that works for you that's great. However a lot of developers end up using Docker abstractions (for very good reasons) such as Lando or Laradock which specifically don't attempt to replicate a production environment any closer than Indigo does. So as @Chrischen says below, use something highly productive for development, and use a clone of your Production Docker stack for QA. Arguably that's the only way to truly be sure your tests pass in your Production environment.

lol sorry about that. It's kinda hard finding the right line in the website promo text between technical detail and something friendly enough to catch visitors' attention.

The premise of running Docker for Mac or other VMs as a development environment is usually so you can run the exact same set of services in development as you run in production. Isolated meaning you can delete the stack, rebuild it, start it up on another machine without any fear of it being affected by macOS updates. With D4M or VMs this is at the expense of not running it directly on your Mac natively, but rather inside the VM.

So to answer your question ("What's it actually do?"), it runs the same services as you might run in docker, with similar upsides (separated from the OS, rebuildable, shareable etc) but without the downsides.

Many developers have experienced first-hand the hassles involved in running D4M or a VM for development. However, those solutions really seem to work for some, so if that's you, Indigo is probably not of interest :)

Anyhow, thanks for the feedback, and if you can suggest anything I could/should say on the site specifically, please do!

Thanks for your feedback. I'm eager for it to actually support the developer, as you'd thought it would. Can you describe more what you'd hoped to see there?

Thanks for your kind feedback. I'm lucky enough to be married to an awesome designer/illustrator who drew them by hand :)

I'm glad Docker works so well for you as the premise is awesome. You're on a Mac right? It's just that you having a bespoke run.sh, and "mounting directories" makes me think Linux, where yes, Docker would be excellent for development.

However, assuming you are on Mac, I'm curious what kind of development you do? It seems hard these days to avoid stuff like `composer update` or `npm update` or to compile SASS or to bundle JS and as soon as you do any of those things, with Docker you start to get a syncing feeling. Sorry, shouldn't try to be funny this late in the day... :)

Oh also, when I run Docker for Mac I often get random 100% CPU usage for no reason at all, with no containers running, causing all my fans to spin up to full. I also periodically find I've run out of SSD space because docker has used it all up with qcows or something. And anytime I had to make a config change in one of my images I had to jump through flaming hoops to get it to take effect in the container. Not because of Docker per-se but because I wanted to write PHP or Javascript, not learn how to sysadmin Docker.

Sounds like you're having some of the kinds of pain I've had in the past. Give Indigo a spin... I'm hoping it will make your life a little better! :)

Ah, "Undo"... good thinking, it's the Mac way :) I'll put it on my list.

Hope you don't mind me continuing the conversation, I like having my thinking challenged/stretched :)

> I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing

Sorry I wasn't clear; my production environments are docker and as such yes, trivial to get running locally. My experience was that this was far less useful than expected. The moment I started turning on things like Xdebug and implementing mechanisms to deal with non-production .envs etc etc it became less and less useful for me. I'm guessing there are workarounds for all these kinds of issues (or you wouldn't be a proponent), but I do suspect that if you're developing locally in a 95+% clone of a production docker environment, you are one of very few who have managed it and enjoyed it enough to keep doing it. Which is to say you're a legend :D

> staging

Perhaps I used poor terminology; call it "Test". And the Pi was a poor example also, sorry! I don't run Pi's, and my personal dev circumstances are fairly atypical. However, I do feel it's solid advice to suggest that people:

a) run whatever development environment is most productive for you on a daily basis locally, so long as it closely replicates the production environment at the level your job requires. So as a front-end / back-end developer that means the same PHP/MySQL/Nginx versions etc.

b) run a clone of your production environment on a separate machine (local VM / local tiny PC / second VPS, whatever) for testing

> specific differences and issues you've seen in ARM linux vs. x86 linux

Absolutely none (as you probably guessed); I've never run an ARM server, nor had any issues between native binaries on x86 or M1 and their identical counterparts in production. As you suggested, the issues I typically face (and many like me, I expect) are at a different abstraction level from this; most boiled down to a) service configuration differences eg PHP extensions or b) file system issues (eg permissions & case sensitivity).

Re VirtioFS no, when I still used D4M I ran docker-sync with various strategies. It kinda worked. I then ran VS Code's Remote Containers. It kinda sorta worked. Both were annoying on an almost-daily basis.

Not so much that MAMP is old as that it's too simple for a lot of work. Essentially:

* MAMP offers a subset of the services Indigo provides (eg MAMP provides two PHPs, Indigo provides seven)

* with Indigo you can run any combination of services all at once if you like (that's a stack in Indigo)

* then in Indigo you can have multiple stacks all running together if you want

* you can share your Indigo stack with a team and have them all running the same stack with one click

So for example, if you maintain a really old Drupal site you might want a stack with PHP 7.2 (or even 5.6) and Apache, and perhaps you're migrating that old site to Laravel, so you'll create a stack with PHP 8.2 and nginx. You can give both their own domain names (eg oldsite.test and newsite.test) and run them both simultaneously. That's super easy to set up in Indigo.

Lol, love it :D

I think my ideal Indigo approach would provide similar functionality to nvm-sh but:

* allow running more than one version at a time (for working on/running multiple projects at differing stages), and

* save you having to install, learn & remember the command line syntax for it; many people find a GUI more productive, despite them often being fully capable of using the command line

Absolutely. The current PHP focus was a handy place to start, but my plan is to incorporate whichever services people find most useful. If you can start a topic in the forums I'm interested to discuss with you how best to cater for node.