I'm probably in the minority here but I would never run this if given the option. Most of the stuff in here has nothing to do with development as is just personal preference. Like what are you hoping to accomplish by dropping `ag` on my PATH? It's just not a tool I use.
The stuff that's specific to development -- go, node, npm, etc. -- sure that makes sense, but installing that stuff via brew is vastly inferior to versioning it as a dependency within your build system. And I'm not saying you have to use bazel or something. Pin your versions, install them by script in the context of your build tools and leave it at that.
I'd reckon the reason you don't see this sort of thing often is because it's not actually useful or necessary. I'd rather follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful.
It's like showing up to a job and them saying "hey we've preconfigured emacs for you."
I'm a professional and take pride in knowing my tools. I can set up my development environment myself. I use Nix where possible and tend to avoid homebrew. Half of these things I have in my dotfiles or nix configs already, as do most of my peers.
I'm sure others will find this useful, and there's certainly nothing harmful about this, but it's certainly not for me, and I'm certain there's a better way to go about handling all these things.
For sure! I can understand that. For people who don’t want to use the script, I also included a list of what is installed in the README. Experienced dev's can manually install and configure what they need.
We have many devs who are fresh out of university or used to windows, so not all are experts with the Linux/Mac command-line. This is helpful for them, and others who just want to start quick.
Mathias Byens' dotfiles repo is a bit like this - https://github.com/mathiasbynens/dotfiles. It's highly opinionated, but I found it extremely useful as a starting point for setting up my own dotfiles. This repo seems simliar to me - the point is the sharing, not necessarily that you'd blindly run it without reading through it.
Really, it depends on what kind of company you're working for.
If you're a BYOD place then sure, let people use their own tools, you have bigger fish to fry.
If you're the place where your auditors require you to deliver proof that all your developers have antivirus installed then it's a different story. The minute you need to take away local administration rights from developers, the value of a standard development environment is immense. No more complaints about not having local administration rights. Plus, the value of hey, my laptop just broke, I ran down to IT, they swapped me out, go back to my desk, log in, and bam, my environment is right like how I left it is huge.
Ultimately - professionals never blame their tools. The hammer handle might not have an ivory handle and tungsten head, but so what? This isn't what bottlenecks you in organizations. And if you really seethe at the thought of emacs being taken away from you, well, switch jobs. The vast majority of the engineering labor force doesn't even know what emacs is.
> I use Nix where possible and tend to avoid homebrew. Half of these things I have in my dotfiles or nix configs already, as do most of my peers.
I think this makes "is this worth using" an entirely different question.
OP's setup script is better than just a "here's your macbook, take some time to get your computer set up".
A tool like Nix is high-effort-high-reward. If everyone's familiar with Nix, it's surely better to use Nix than to use OP's setup script. If not, whether Nix is the better way to do things is arguable.
I am 100% with you. I did some consulting work for a startup that had this kind of thing. “Oh you are having trouble with our dev environment? We have a small script that will get you going.” Script turns out to install shit like Zoom, VS Code, Slack, reconfiguring paths, fucking up my dot files, installing and configuring Docker, etc. It was a mess and there was no reason for most of it and the parts that were needed were already broken.
Even homebrew is a little too opinionated for me. If I could run some specific bits of Mac software on Linux I would never leave Ubuntu. apt is a joy to use by comparison to all this BS.
it's more of just a script a newer company will use to do the initial setup for laptops. Great starting point if you have security and preferred software before the new hire's first day.
> I'd rather follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful.
I rewrote the onboarding documentation of my team and asked myself if I should script the tooling installation. I came with the same conclusion and just gave a list of tools to absolutely install (with a suggestion of how to install it, but do as you please) and recommended tools and extensions (+ why they're cool). I think this approach is especially useful for newbies who don't necessarily know the tools or how to install them.
If anybody has an issue with their custom installation though, I redirect them to the onboarding recommendations.
I'd rather provide a docker image, if you want something prebuilt for a developer. And yes, I wouldn't run a script like that on any machine I use, but I do understand how it could be useful for someone starting out.
> I'm a professional and take pride in knowing my tools.
But some people aren’t professionals. They may be hobbyists or people who just entered the field. And the barrier to entry is becoming higher and higher with the rising importance of devops. It’s very daunting to try to get into a new tech stack and follow the best practices without much guidance.
Exactly. I’d be really bummed if I started a new job and was expected to run this script. It’s like they’re saying they’ve found and encapsulated the most productive development experience you could ask for and they’re going to shove it down your throat.
You should give your hires the respect they deserve and treat them like professionals letting them use their own tools. Just give them a mac and let them do their thing.
This script helps new developers at my workplace setup their MacBook laptops quick, letting them hit the ground running.
Before this script, it could take 2-5 days to install and configure everything, as much of the knowledge needed was either scattered in old docs or passed down verbally from a few senior devs.
With this script, new developers can be ready in under 30 min.
I have tried to make this script simple and useful. You will want to customize the installation and configuration to match the tools and services you use at your company.
Note: it has not been tested on M1 Macs yet. I am still waiting on my M1 and will update when I receive it
2-5 days that’s nothing. I once billed a customer an entite months worth of hours because they had a super weird and complex development setup with scripts, proxies, vpn and all that good stuff. But when the AD groups are trash and no one knows what’s going on, well, that was fortunately for me their problem, which they were well aware of, and working hard to replace with a local k8s setup. And lets leave it at that.
This is handy. I could never figure out how to reliably use a Finder window to navigate to a specific directory so I resorted to running "open ." from the directory in the terminal.
Here's some feedback if it's helpful for the author.
As mentioned in the comments, the script is supposed to cover fresh grads and Windows users with no prior Linux/macOS experience.
The experienced users having their own opinion about the configuration would still require time to find and configure company-specific conventions and settings they're not aware of. The common reaction is such opinionated scripts are avoided at any cost, so developers still spend time filtering the file(s) to find important bits. If the information is also in the documentation, it's ok - the script can be safely ignored. Otherwise, it can be annoying and leave a bad impression.
For the next version, I'd try to make it friendlier for both groups of users. I'd say being able to revisit what exactly is to be installed would enable more people, save time and energy. The experts would only get necessary business settings integrated (via the advanced mode), while beginners would have complete installation (via the basic mode). It was a pretty common approach with TUI installers back in the day.
Homebrew-wise, I'd replace separate brew commands with a Brewfile and 'brew bundle install'. It'd keep the package list isolated from the logic. Regarding the packages, I'd also put all version-sensitive software away from the direct Homebrew control. With programming languages, it'd be a version manager like 'asdf' and so on.
I haven't invested in a Nix configuration yet, since my small dotfiles repo works fine so far. There are obvious benefits, of course.
As a long time brew and Mac user who keeps his Linux/Mac environments in relative sync, I find these scripts fascinating, but would ultimately never, ever run anything like this, especially anything related to system-level tweaks.
That said, relying on brew to set up the language runtimes is a sane option. I just don't think the script should go anywhere beyond that.
Can someone advise if the script is idempotent? That's something I've never bothered with my own setup scripts, but really would be satisfying. Hoping to nerd snipe someone here =]
While developing it, I have run it a great number of times on my own computer (in addition to testing on clean MacOS install VMs) and it will only install what is missing. So, yep!
Haha. Doubtful. That's the problem of not using proper configuration management tools and playing "emperor's new clothes" by throwing proven approaches away for "quick" or "easy."
2-5 days? I'm curious, is that because you don't have anyone who has bandwidth to do ops (making end users manually do everything), or something else? Seems to me that most of this should just be installed via JAMF or your MDM of choice, so people can just take the laptop out of the box and be ready to rock once it syncs.
(Of course, the user will still have to get brew themselves most likely so the permissions are right, but everything else can be done on a system-wide level and be zero-touch for the end user.)
edit: Sorry if this sounded snarky, I didn't intend it to be. Everyone has to allocate resources somehow. If you ever have time for a weekend project, I'd look up the cloud version of JAMF ($3 per device per month) or Intune (approximately the same if you have Microsoft services). Couple days of work and you'll have a much easier end-user experience.
It's also not too hard to make your own, be it for MacOS or really any modern operating system. Just write down all of the changes you make on a fresh install, script out each line and you're pretty much golden. It's definitely a lifesaver when stepping onto a new machine.
My work group has adopted this as a rule. We do mostly R&D lab work rather than customer facing software development, and often a single computer is dedicated to a specific project. We want to make sure that the entire project can be replicated on another computer or hardware setup if needed.
This script is also worth reviewing with colleagues, to avoid pitfalls and also as a way to share better techniques.
I never understood the argument of _helping fellow developers out_ by setting up their development environment or _lowering the entrance bar_ as everything got so complicated really.
For one, I personally cannot trust the technical competence of a fellow developer if he/she cannot handle their setup him/herself. We're talking installing tools by clicking around, aren't we? The same argument holds true for a fellow plumber that has never worked with this pipe system in particular.
Second, there's much to discover by installing and setting up everything by oneself. It can give insights on how things are connected to each other tool wise which is the first step of getting familiar with a new environment in the first place anyways.
Nice work! I’ve used a similar script for Ruby dev (actually I use it as a reference rather than just running it, but still useful): https://github.com/thoughtbot/laptop
The oldest commits on this script are 11 years old and nothing in the last year, which seems quite stable. At the same time I was able to ask an intern to just run it last week, and bam! they have everything they need installed.
One use for it that surprised me was hearing a colleague saying that he reinstalls his OS after every change of client and runs the setup script again so there’s no fear of IP theft but also no downtime from having an unconfigured machine.
This script installs all packages that I use, links all the dotfiles, all dockerfiles, all services, docker networks, setups all virtual hosts, and the new workstation is ready to use in 15 minutes. Before this script, it would take days to properly set a workstation up as I'd always forget something (missing file or configuration options).
At work we use a mixture of Bazel and Nix for our repo. Bazel drives everything, but Nix is used for its wide array of prebuilt third-party packages. Nix gives us e.g. python, postgres, clang, and various other utilities.
We have a mixture of python, java, go, protobuf, and node. The only tools a new developer needs to install are bazelisk and nix. Everything else is fetched as needed during build/test.
This sounds like a nice setup. I've been using Bazel for some years, but it's always been a struggle to make other people use it :) For some quite understandable reasons. I also really would like to use one tool, either Nix or Bazel I don't care, but unfortunately, even though Nix is positioning itself as a build system, it really doesn't work very well to offer fast feedback loop and incrementality necessary in development.
How do you make your IDE happy about Bazel managing your external dependencies? I mean, autocomplete and stuff like that.
Something I've not seen done, but to me seems like it would be much more useful than a shell script (or maybe would have, in these tools' heyday), would have been to use a tool like Chef or Ansible to manage dev dependencies on developer laptops.
The trouble with shell scripts is that they generally require you to manage the state of the machine - whether or not something is installed, before I go install and configure it. Or, if it's already configured, what configs to leave in place, and what configs to reset.
With Chef, for instance, everything's declarative. I don't say "install this package"; rather, I say "this package should be installed". Nobody ever runs the setup script just once, since the dev environment is constantly changing, and all of those edge cases (maybe I last ran it on rev 3, or rev 7 - how do I get to rev 12?) become hard to manage.
I've actually done this before with Ansible, but it still required a bootstrapping script. Basically it installs homebrew, then Ansbile, asks a few setup questions, clones a git repo with the rest of the setup process, and then kicks off the Ansible script. The dev environment has a lot of legacy stuff in it and has been grown over years so it's difficult to break it down into simpler pieces. It works surprisingly well in comparison to trying to do things manually or the old mixed manual/pure shell script approach.
That said, it's also surprisingly finicky. The scripts have to be regularly maintained or things keep changing out from under you and causing problems. Especially if you need to support more than one platform (i.e. macOs and a Linux say...).
Boxen (https://github.com/boxen/puppet-boxen) used Puppet to achieve this. It worked, but it was quite opinionated and of course you needed to know Puppet so the learning curve was steep. It's since been superseded by Homebrew which I find is a far better experience.
asdf and pyenv are both fine answers in my opinion.
I use asdf just to avoid having pyenv + rbenv + nodenv + javaenv installed, and it works fine.
Homebrew has its own python installation, but I make sure to always use the one installed by asdf, they don't touch each other and everything works ok.
I make sure nothing uses the system python other than any system tools that do it without my knowledge.
[+] [-] xyzzy_plugh|4 years ago|reply
The stuff that's specific to development -- go, node, npm, etc. -- sure that makes sense, but installing that stuff via brew is vastly inferior to versioning it as a dependency within your build system. And I'm not saying you have to use bazel or something. Pin your versions, install them by script in the context of your build tools and leave it at that.
I'd reckon the reason you don't see this sort of thing often is because it's not actually useful or necessary. I'd rather follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful.
It's like showing up to a job and them saying "hey we've preconfigured emacs for you."
I'm a professional and take pride in knowing my tools. I can set up my development environment myself. I use Nix where possible and tend to avoid homebrew. Half of these things I have in my dotfiles or nix configs already, as do most of my peers.
I'm sure others will find this useful, and there's certainly nothing harmful about this, but it's certainly not for me, and I'm certain there's a better way to go about handling all these things.
[+] [-] joelkesler|4 years ago|reply
For sure! I can understand that. For people who don’t want to use the script, I also included a list of what is installed in the README. Experienced dev's can manually install and configure what they need.
We have many devs who are fresh out of university or used to windows, so not all are experts with the Linux/Mac command-line. This is helpful for them, and others who just want to start quick.
Update: clarifications
[+] [-] frereubu|4 years ago|reply
[+] [-] fmakunbound|4 years ago|reply
Good god, that’s like wearing someone else’s dirty underwear.
[+] [-] solatic|4 years ago|reply
If you're a BYOD place then sure, let people use their own tools, you have bigger fish to fry.
If you're the place where your auditors require you to deliver proof that all your developers have antivirus installed then it's a different story. The minute you need to take away local administration rights from developers, the value of a standard development environment is immense. No more complaints about not having local administration rights. Plus, the value of hey, my laptop just broke, I ran down to IT, they swapped me out, go back to my desk, log in, and bam, my environment is right like how I left it is huge.
Ultimately - professionals never blame their tools. The hammer handle might not have an ivory handle and tungsten head, but so what? This isn't what bottlenecks you in organizations. And if you really seethe at the thought of emacs being taken away from you, well, switch jobs. The vast majority of the engineering labor force doesn't even know what emacs is.
[+] [-] rgoulter|4 years ago|reply
I think this makes "is this worth using" an entirely different question.
OP's setup script is better than just a "here's your macbook, take some time to get your computer set up".
A tool like Nix is high-effort-high-reward. If everyone's familiar with Nix, it's surely better to use Nix than to use OP's setup script. If not, whether Nix is the better way to do things is arguable.
[+] [-] IgorPartola|4 years ago|reply
Even homebrew is a little too opinionated for me. If I could run some specific bits of Mac software on Linux I would never leave Ubuntu. apt is a joy to use by comparison to all this BS.
[+] [-] chidog12|4 years ago|reply
[+] [-] throwaddzuzxd|4 years ago|reply
I rewrote the onboarding documentation of my team and asked myself if I should script the tooling installation. I came with the same conclusion and just gave a list of tools to absolutely install (with a suggestion of how to install it, but do as you please) and recommended tools and extensions (+ why they're cool). I think this approach is especially useful for newbies who don't necessarily know the tools or how to install them.
If anybody has an issue with their custom installation though, I redirect them to the onboarding recommendations.
[+] [-] aledalgrande|4 years ago|reply
[+] [-] LudwigNagasena|4 years ago|reply
But some people aren’t professionals. They may be hobbyists or people who just entered the field. And the barrier to entry is becoming higher and higher with the rising importance of devops. It’s very daunting to try to get into a new tech stack and follow the best practices without much guidance.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] johnwheeler|4 years ago|reply
You should give your hires the respect they deserve and treat them like professionals letting them use their own tools. Just give them a mac and let them do their thing.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] stephenr|4 years ago|reply
[+] [-] joelkesler|4 years ago|reply
This script helps new developers at my workplace setup their MacBook laptops quick, letting them hit the ground running.
Before this script, it could take 2-5 days to install and configure everything, as much of the knowledge needed was either scattered in old docs or passed down verbally from a few senior devs.
With this script, new developers can be ready in under 30 min.
I have tried to make this script simple and useful. You will want to customize the installation and configuration to match the tools and services you use at your company.
Note: it has not been tested on M1 Macs yet. I am still waiting on my M1 and will update when I receive it
[+] [-] spyke112|4 years ago|reply
[+] [-] gumby|4 years ago|reply
There’s no need to chmod your script, just invoke it with sh.
[+] [-] nodesocket|4 years ago|reply
[+] [-] oplav|4 years ago|reply
[+] [-] shiloa|4 years ago|reply
[+] [-] GVRV|4 years ago|reply
[+] [-] unbanned|4 years ago|reply
[+] [-] spywhere|4 years ago|reply
Moreover, I think I have more options to skip particular part / packages while also try to be idempotent as much as it can.
https://github.com/spywhere/dotfiles
[+] [-] setheron|4 years ago|reply
Using these scripts as a way to give "reproducible" build environments is just doomed.
[+] [-] thatguydidit|4 years ago|reply
a well loved and maintained ansible playbook for macs.
Just FYI
[+] [-] joelkesler|4 years ago|reply
[+] [-] koirapoika|4 years ago|reply
As mentioned in the comments, the script is supposed to cover fresh grads and Windows users with no prior Linux/macOS experience.
The experienced users having their own opinion about the configuration would still require time to find and configure company-specific conventions and settings they're not aware of. The common reaction is such opinionated scripts are avoided at any cost, so developers still spend time filtering the file(s) to find important bits. If the information is also in the documentation, it's ok - the script can be safely ignored. Otherwise, it can be annoying and leave a bad impression.
For the next version, I'd try to make it friendlier for both groups of users. I'd say being able to revisit what exactly is to be installed would enable more people, save time and energy. The experts would only get necessary business settings integrated (via the advanced mode), while beginners would have complete installation (via the basic mode). It was a pretty common approach with TUI installers back in the day.
Homebrew-wise, I'd replace separate brew commands with a Brewfile and 'brew bundle install'. It'd keep the package list isolated from the logic. Regarding the packages, I'd also put all version-sensitive software away from the direct Homebrew control. With programming languages, it'd be a version manager like 'asdf' and so on.
I haven't invested in a Nix configuration yet, since my small dotfiles repo works fine so far. There are obvious benefits, of course.
[+] [-] rcarmo|4 years ago|reply
That said, relying on brew to set up the language runtimes is a sane option. I just don't think the script should go anywhere beyond that.
[+] [-] jonchurch_|4 years ago|reply
[+] [-] joelkesler|4 years ago|reply
While developing it, I have run it a great number of times on my own computer (in addition to testing on clean MacOS install VMs) and it will only install what is missing. So, yep!
[+] [-] errcorrectcode|4 years ago|reply
[+] [-] llimllib|4 years ago|reply
You might find it useful for a base for your own? up to you.
[+] [-] easton|4 years ago|reply
(Of course, the user will still have to get brew themselves most likely so the permissions are right, but everything else can be done on a system-wide level and be zero-touch for the end user.)
edit: Sorry if this sounded snarky, I didn't intend it to be. Everyone has to allocate resources somehow. If you ever have time for a weekend project, I'd look up the cloud version of JAMF ($3 per device per month) or Intune (approximately the same if you have Microsoft services). Couple days of work and you'll have a much easier end-user experience.
[+] [-] smoldesu|4 years ago|reply
[+] [-] analog31|4 years ago|reply
This script is also worth reviewing with colleagues, to avoid pitfalls and also as a way to share better techniques.
[+] [-] W0lf|4 years ago|reply
For one, I personally cannot trust the technical competence of a fellow developer if he/she cannot handle their setup him/herself. We're talking installing tools by clicking around, aren't we? The same argument holds true for a fellow plumber that has never worked with this pipe system in particular.
Second, there's much to discover by installing and setting up everything by oneself. It can give insights on how things are connected to each other tool wise which is the first step of getting familiar with a new environment in the first place anyways.
[+] [-] zingar|4 years ago|reply
The oldest commits on this script are 11 years old and nothing in the last year, which seems quite stable. At the same time I was able to ask an intern to just run it last week, and bam! they have everything they need installed.
One use for it that surprised me was hearing a colleague saying that he reinstalls his OS after every change of client and runs the setup script again so there’s no fear of IP theft but also no downtime from having an unconfigured machine.
[+] [-] pkrumins|4 years ago|reply
http://github.com/pkrumins/install-computer/blob/master/inst...
This script installs all packages that I use, links all the dotfiles, all dockerfiles, all services, docker networks, setups all virtual hosts, and the new workstation is ready to use in 15 minutes. Before this script, it would take days to properly set a workstation up as I'd always forget something (missing file or configuration options).
[+] [-] rounakdatta|4 years ago|reply
[+] [-] jvolkman|4 years ago|reply
We have a mixture of python, java, go, protobuf, and node. The only tools a new developer needs to install are bazelisk and nix. Everything else is fetched as needed during build/test.
[+] [-] burdiyan|4 years ago|reply
How do you make your IDE happy about Bazel managing your external dependencies? I mean, autocomplete and stuff like that.
[+] [-] don-code|4 years ago|reply
The trouble with shell scripts is that they generally require you to manage the state of the machine - whether or not something is installed, before I go install and configure it. Or, if it's already configured, what configs to leave in place, and what configs to reset.
With Chef, for instance, everything's declarative. I don't say "install this package"; rather, I say "this package should be installed". Nobody ever runs the setup script just once, since the dev environment is constantly changing, and all of those edge cases (maybe I last ran it on rev 3, or rev 7 - how do I get to rev 12?) become hard to manage.
[+] [-] mhio|4 years ago|reply
[+] [-] emeraldd|4 years ago|reply
That said, it's also surprisingly finicky. The scripts have to be regularly maintained or things keep changing out from under you and causing problems. Especially if you need to support more than one platform (i.e. macOs and a Linux say...).
[+] [-] typhonius|4 years ago|reply
[+] [-] indigodaddy|4 years ago|reply
[+] [-] winrid|4 years ago|reply
[+] [-] ZeroGravitas|4 years ago|reply
What is the current state of the art with python on Mac?
Python 2->3, brew vs core install and pyenv changes all seem to combine to make it a pain.
asdf as a generic "use this version of language/runtime in this directory/project" seems like it might be the future, but isn't quite the norm now.
Anyone experienced with Python on Mac have any informed opinions to share?
[+] [-] llimllib|4 years ago|reply
I use asdf just to avoid having pyenv + rbenv + nodenv + javaenv installed, and it works fine.
Homebrew has its own python installation, but I make sure to always use the one installed by asdf, they don't touch each other and everything works ok.
I make sure nothing uses the system python other than any system tools that do it without my knowledge.