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.<p>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 <i>in the context of your build tools</i> and leave it at that.<p>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 <i>rather</i> follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful.<p>It's like showing up to a job and them saying "hey we've preconfigured emacs for you."<p>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.<p>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.
Author here:<p>This script helps new developers at my workplace setup their MacBook laptops quick, letting them hit the ground running.<p>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.<p>With this script, new developers can be ready in under 30 min.<p>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.<p>Note: it has not been tested on M1 Macs yet. I am still waiting on my M1 and will update when I receive it
<p><pre><code> defaults write com.apple.finder ShowPathbar -bool true
</code></pre>
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.
I did the same with my dotfiles setup, but it's for my personal preferences.<p>Moreover, I think I have more options to skip particular part / packages while also try to be idempotent as much as it can.<p><a href="https://github.com/spywhere/dotfiles" rel="nofollow">https://github.com/spywhere/dotfiles</a>
<a href="https://github.com/geerlingguy/mac-dev-playbook" rel="nofollow">https://github.com/geerlingguy/mac-dev-playbook</a><p>a well loved and maintained ansible playbook for macs.<p>Just FYI
Here's some feedback if it's helpful for the author.<p>As mentioned in the comments, the script is supposed to cover fresh grads and Windows users with no prior Linux/macOS experience.<p>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.<p>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.<p>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.<p>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.<p>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 =]
I keep a personal one that is somewhat simpler, and uses asdf for node, python, ruby etc: <a href="https://gist.github.com/llimllib/3fc4fefcfc0152dad8c58201246d8802" rel="nofollow">https://gist.github.com/llimllib/3fc4fefcfc0152dad8c58201246...</a><p>You might find it useful for a base for your own? up to you.
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.<p>(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.)<p>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.
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.<p>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.<p>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): <a href="https://github.com/thoughtbot/laptop" rel="nofollow">https://github.com/thoughtbot/laptop</a><p>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.<p>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.
I made something similar. Whenever I install a new workstation that runs Linux, I run this script:<p><a href="http://github.com/pkrumins/install-computer/blob/master/install.sh" rel="nofollow">http://github.com/pkrumins/install-computer/blob/master/inst...</a><p>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).
I as well attempted to structure such tasks better with Ansible, <a href="https://github.com/rounakdatta/computer.setup" rel="nofollow">https://github.com/rounakdatta/computer.setup</a>. :)
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.<p>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.
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.<p>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.<p>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.
The bits about Python caught my eye.<p>What is the current state of the art with python on Mac?<p>Python 2->3, brew vs core install and pyenv changes all seem to combine to make it a pain.<p>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.<p>Anyone experienced with Python on Mac have any informed opinions to share?
Nice - i learned few tricks from there.
for the mac setup, I have been using this for years and works well for me.
<a href="https://github.com/geerlingguy/mac-dev-playbook" rel="nofollow">https://github.com/geerlingguy/mac-dev-playbook</a>