How you run something on your computer often ends up different than how you run it on your cluster.
And how you test things usually ends up different than how you actually run them.
I was wondering if we could add some standard way to add custom environmental configurations.
With this, for example, you could tell your code to use:
I guess I am still in denial then 
I run my code with the same precision, and actually the exact same setup on my puny laptop and our multicore computational server. It’s just that for an iterative algorithm, I run a few hundred iterations on my laptop, profile, try to optimize the bottlenecks, then sync to the server and start it there.
If I used different precisions, I would be concerned about not optimizing the right thing (both cache and CPU effects). Of course the laptop and the server CPUs are different, but I found it not worthwhile to optimize for that. (Also, using single precision would pretty much kill most of my algorithms, or force me to be too clever all the time).
If your code is type generic, you just pass different types into it into your tests to get a different precision. There’s no reason for this to be a different environment, and this is a good test to make sure you haven’t accidentally hardcoded a type to Float64 anywhere.
The precision example was just supposed to be an example.
I’m talking about anything that might be a little different depending on how you run it.
Off the top of my head, this could include setting:
For simple configuration options like API endpoints I generally use the same tactics I use for node and Angular projects – look for environment variables or a key in a config.json or similar before possibly falling back to a default value.
The vastly harder problem is keeping consistent Julia package environments across deployments, which could potentially be solved by Pkg3 if/when it lands.
Right now my nightmare situation goes as follows: I find a bug in some product that I’ve released to production. I pull it up on my development machine, but it doesn’t run because I ran Pkg.update() the previous week which introduced breaking changes in a few packages (or if it’s a module, I have conflicting version requirements between it and other modules). I then either need to temporarily check out old versions of the affected packages, or make a bunch of modifications just to get it running again (and then also update the packages in prod).
The Pkg3 julep does a good job of explaining how we got here. It’s not that Pkg2 screwed something up – it’s just optimized for a different situation where all julia code on a system uses the same version (and prevents us from hauling around a bunch of different copies of every module).