13 ms·

Show HN: We open sourced our new Mac developer setup script

169 points by joelkesler 5y ago

rounakdatta 5y ago
I as well attempted to structure such tasks better with Ansible, https://github.com/rounakdatta/computer.setup https://github.com/rounakdatta/computer.setup. :)
ZeroGravitas 5y ago
The bits about Python caught my eye. 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 5y ago
  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.
oweiler 5y ago
I recommend using as few tools as possibly so that you don't need such a script.
joelkesler 5y ago
Author here: 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
- nodesocket 5y ago
  Seems like Docker + Docker Compose or GitHub Codespaces would simplify things greatly in terms of developer tooling install and setup.
  - duped 5y ago
    Has docker performance improved on MacOS recently?
    - nodesocket 5y ago
      I run development and testing Docker workloads on a 16” M1 Max just fine. Runs native Apple Silicon (arm64)
      - duped 5y ago
        I'm more interested in comparative benchmarks. The last I heard MacOS (Intel) running docker was significantly slower than Linux and M1 was just as bad if not worse through Rosetta. My experience in running the odd docker container on a Mac has been that it was painfully slow compared to any Linux machine.
    - Casteil 5y ago
      From an M1 standpoint, the engine has been M1-native for a while - there's also a more recent update that makes the Docker Desktop UI/services M1-native.
      - errcorrectcode 5y ago
        Well the Engine maybe native, but how is it running the necessary x86_64 Linux VM under HyperKit?
        nodesocket 5y ago
        I don't believe it does, stil get arm64 Docker images. However, there is an experimental mode with Docker Desktop that allows for multiple architecture builds using buildx[1] but I have not tried it. [1] https://docs.docker.com/engine/reference/commandline/buildx/ https://docs.docker.com/engine/reference/commandline/buildx/
xodltus 5y ago
If I use this with a little modification, I think it will be useful to me
llimllib 5y ago
I keep a personal one that is somewhat simpler, and uses asdf for node, python, ruby etc: https://gist.github.com/llimllib/3fc4fefcfc0152dad8c58201246d8802 https://gist.github.com/llimllib/3fc4fefcfc0152dad8c58201246... You might find it useful for a base for your own? up to you.
smoldesu 5y ago
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.
- analog31 5y ago
  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.
  - errcorrectcode 5y ago
    Seems wasteful. Use VMs or containers that can be backed-up and transported to other machines. Also, look into automated configuration management because manual meat monkeying is so 1997.
    - analog31 5y ago
      For better or worse, a lot of it is 1997 technology, for instance, hardware modules of different brands and antediluvian driver installers. And part of the point is not just to know that it can be copied, but that we actually record what the installation process consisted of.
dwelch2344 5y ago
Looks good. We’re publishing ours soon. You should ditch nvm for Volta. It’s insanely better
- wildrhythms 5y ago
  What are some reasons to switch from nvm to Volta?
  - adam_beck 5y ago
    It's faster and cross-platform (Windows/Linux/MacOS). Switching version managers is trivial. If you don't like it, just switch back in the time it takes to uninstall a binary.
    - pjerem 5y ago
      Last time I tried it, it totally broke my WebStorm setup (on Windows).
- filmgirlcw 5y ago
  +1 for Volta. Finally switched to it for my own setup this week and it’s just so much easier. Big, big fan.
- joelkesler 5y ago
  I have been watching Volta. It looks pretty great.
- gizdan 5y ago
  Better yet, use asdf. It supports more than just node. I manage go, node, python, terraform, direnv, and many more with it.
- petepete 5y ago
  Of the alternatives I like fnm the most. It's a single binary, blazing fast and just works how you'd expect it to.
jonchurch_ 5y ago
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 =]
- errcorrectcode 5y ago
  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."
- joelkesler 5y ago
  Author 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!
don-code 5y ago
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.
- indigodaddy 5y ago
  Is declarative related to (or maybe leads to) idempotency?
  - kubanczyk 5y ago
    Declarativeness (vs imperativeness) is the property of a language. Whether it allows you to express the desired state, as opposed to a sequence of simple operations. Idempotency is the runtime behavior. You can absolutely write idempotent program using imperative language (case in point: chef and its recipe can be expressed as machine code, which is a very imperative language, yet it is idempotent when you run it).
    - indigodaddy 5y ago
      Thanks for this explanation!
- emeraldd 5y ago
  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...).
r-w 5y ago
This is fantastic!!! Also: no love for fish? ;)
- joelkesler 5y ago
  I haven’t reached that level of enlightenment yet :)
  - couponsva 5y ago
    Thank you for this idea. Christmas is coming and this is a nice gift to get especially if you are too busy and forget to do shopping https://couponsva.com/store/macys https://couponsva.com/store/macys
xyzzy_plugh 5y ago
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.
- chidog12 5y ago
  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.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- joelkesler 5y ago
  Author here: 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
spywhere 5y ago
I did the same with my dotfiles setup, but it's for my personal preferences. 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 https://github.com/spywhere/dotfiles
- tomcam 5y ago
  I think you should post this separately. It appears to of been painstakingly developed over a long time and has an array of options I would expect from a professional setup.
  - spywhere 5y ago
    It definitely been working on for quite some time. I start working on it as a simple setup with just `Brewfile` for brew bundle, then adding custom comments to run grep + xargs to pipe to Aptitude / APK / package manager to install the same package for different platforms. I find myself constantly either in need of reinstalling the whole OS or setup my environment a lot, hence I need to make the setup flexible and various options to better reduce the time I spent manually install stuffs.
- sirn 5y ago
  Ha, I also have something similar[1], but I use a mix of profiles and flavors. I have two profiles: pkg for installing packages and user for configuring user profiles. Profiles are then broken down further with flavors: dev for development packages, desktop for desktop packages and configurations, and so on. I found it highly amusing that we're taking similar approaches for a lot of things: a wrapper function for sudo and fetch, and OS detection (especially the appending WSL suffix part). Mine is not as idempotent as yours, and having a per-package definition is still in my TODO list, though. [1]: https://github.com/sirn/dotfiles https://github.com/sirn/dotfiles
pkulak 5y ago
Do you still have to wait for all 12 gigs of xcode to download and extract, then agrees to terms before you can use git?
- easton 5y ago
  "xcode-select --install" grabs only the command line utilities included with Xcode (git, swift, clang, python3.8, etc), and it's only 400MB on my machine. That command has been there for a while, since Leopard or so, and Homebrew prompts you to run it before you continue with installing brew.
  - TomatoTomato 5y ago
    Just typing `git` works too
  - pkulak 5y ago
    Macports still says to download xcode in full first: https://guide.macports.org/#installing.xcode https://guide.macports.org/#installing.xcode Any idea why that is? Is it out of date?
    - saagarjha 5y ago
      It’s not required, unless you decide to install something that needs it. Most packages don’t need it at all these days.
easton 5y ago
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.
errcorrectcode 5y ago
Sorry, but configuration management supersedes setup scripts. This isn't interesting.
oplav 5y ago
defaults write com.apple.finder ShowPathbar -bool true 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.
- shiloa 5y ago
  I found Cmd+Shift+G in finder handy. It'll open a text box to type your desired path and supports tab completions.
- GVRV 5y ago
  You can open a finder window, press `Cmd + Shift + G` to navigate to a path easily.
- unbanned 5y ago
  This is where MS Windows really shines is window management. It sucks on a Mac and quickly feels cluttered.
Uptrenda 5y ago
I find this completely boring and un-newsworthy.
meabed 5y ago
Nice - i learned few tricks from there. for the mac setup, I have been using this for years and works well for me. https://github.com/geerlingguy/mac-dev-playbook https://github.com/geerlingguy/mac-dev-playbook
winrid 5y ago
I've found that using ansible works pretty well for setting up dev machines.
deleted 5y ago
[deleted]
thatguydidit 5y ago
https://github.com/geerlingguy/mac-dev-playbook https://github.com/geerlingguy/mac-dev-playbook a well loved and maintained ansible playbook for macs. Just FYI
- joelkesler 5y ago
  Thanks! I will take a look
setheron 5y ago
This script is a great pitch why Nix is the future. Using these scripts as a way to give "reproducible" build environments is just doomed.
jvolkman 5y ago
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.
- burdiyan 5y ago
  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.
  - jvolkman 5y ago
    Ideally your IDE supports Bazel. There's a Bazel plugin for Intellij that works reasonable well for Java. We use python primarily, and while this plugin does support Python a bit, it's got some issues. So we wrote a bazel rule that builds a python virtualenv using Bazel dependencies and that bridges the gap to allow use of "legacy" tooling.
    - burdiyan 5y ago
      Nice! I was thinking about something like that too. E.g. building symlinks for all the deps into a local directory and use it as PYTHONPATH. I tried it with your example on GitHub and it worked. And then if all the developers are using something like direnv[1] this PYTHONPATH variable could easily be set for everyone. How do you manage dependencies for the fine-grained Bazel targets (like py_library)? Do you write them manually or using some language-specific tools like Gazelle? If you do use the tool, do you have anything in place to automate it? Couple years ago I had a pretty bad experience with people complaining about having to execute Gazelle manually. In my ideal world view I'd want to add an import statement in code and just run `bazel build`. So I ended having a wrapper that would run Gazelle before running Bazel all the time, but it slowed thing down quite a bit, because it was doing a lot of unnecessary work. [1]: https://direnv.net https://direnv.net
W0lf 5y ago
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.
- bluedino 5y ago
  I worked at a small Rails shop a long time ago. Everyone had their Mac setup differently (they each did the setup themselves), and nobody really knew how theirs was setup. Until something broke. Development domain names - some people used /etc/hosts, some people used pow, others used PassengerPane. For packages, a few people used Brew, some used MacPorts... In the end we went with a standard setup where I implemented things like rvm (we had both Rails 2 and Rails 3 apps). And even created a CentOS setup script which was as similar as possible.
- akyoan 5y ago
  "I cannot trust your competence as a developer if you can't build your compiler in assembly." These setups are useful because: - not everyone needs to start from scratch every time - they share one’s known-how through their configuration Even if I rarely use boilerplates and such, often they're good resources to see how a specific problem has been fixed. Also if they're done well they lower the barrier of entry considerably. See create-react-app where you can start developing something serious in React without starting from an empty index.html and glue everything together.
- danjac 5y ago
  A new developer of decent competence in your tech stack should be able to go from zero to first commit in a few hours. If that's not possible then you have a technical debt problem that's probably a smell for other issues in your code base. Sometimes the complexity is unavoidable - e.g. loading some large training data set or a complicated tool chain of some essential libraries - in which case you should automate away as much as possible in build scripts. Sometimes the setup complexity is due to poor maintenance - "we used Gulp 3 years ago, but switched to Webpack last year, and the frontend guys are trying out esbuild, but there's still stuff that's running under Webpack and we need Gulp for these couple old pages over there". Either way, there's no better way to crush the enthusiasm of a new hire than have them bogged down in your shitty install setup on their first day.
zingar 5y ago
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 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.
rcarmo 5y ago
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.
koirapoika 5y ago
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.
pkrumins 5y ago
I made something similar. Whenever I install a new workstation that runs Linux, I run this script: http://github.com/pkrumins/install-computer/blob/master/install.sh 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).

169 points by joelkesler 5y ago

I as well attempted to structure such tasks better with Ansible, https://github.com/rounakdatta/computer.setup https://github.com/rounakdatta/computer.setup. :)

ZeroGravitas 5y ago

The bits about Python caught my eye. 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 5y ago
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.

oweiler 5y ago

I recommend using as few tools as possibly so that you don't need such a script.

joelkesler 5y ago

Author here: 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

nodesocket 5y ago
Seems like Docker + Docker Compose or GitHub Codespaces would simplify things greatly in terms of developer tooling install and setup.
- duped 5y ago
  Has docker performance improved on MacOS recently?
  - nodesocket 5y ago
    I run development and testing Docker workloads on a 16” M1 Max just fine. Runs native Apple Silicon (arm64)
    - duped 5y ago
      I'm more interested in comparative benchmarks. The last I heard MacOS (Intel) running docker was significantly slower than Linux and M1 was just as bad if not worse through Rosetta. My experience in running the odd docker container on a Mac has been that it was painfully slow compared to any Linux machine.
  - Casteil 5y ago
    From an M1 standpoint, the engine has been M1-native for a while - there's also a more recent update that makes the Docker Desktop UI/services M1-native.
    - errcorrectcode 5y ago
      Well the Engine maybe native, but how is it running the necessary x86_64 Linux VM under HyperKit?
      - nodesocket 5y ago
        I don't believe it does, stil get arm64 Docker images. However, there is an experimental mode with Docker Desktop that allows for multiple architecture builds using buildx[1] but I have not tried it. [1] https://docs.docker.com/engine/reference/commandline/buildx/ https://docs.docker.com/engine/reference/commandline/buildx/

xodltus 5y ago

If I use this with a little modification, I think it will be useful to me

llimllib 5y ago

I keep a personal one that is somewhat simpler, and uses asdf for node, python, ruby etc: https://gist.github.com/llimllib/3fc4fefcfc0152dad8c58201246d8802 https://gist.github.com/llimllib/3fc4fefcfc0152dad8c58201246... You might find it useful for a base for your own? up to you.

smoldesu 5y ago

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.

analog31 5y ago
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.
- errcorrectcode 5y ago
  Seems wasteful. Use VMs or containers that can be backed-up and transported to other machines. Also, look into automated configuration management because manual meat monkeying is so 1997.
  - analog31 5y ago
    For better or worse, a lot of it is 1997 technology, for instance, hardware modules of different brands and antediluvian driver installers. And part of the point is not just to know that it can be copied, but that we actually record what the installation process consisted of.

dwelch2344 5y ago

Looks good. We’re publishing ours soon. You should ditch nvm for Volta. It’s insanely better

wildrhythms 5y ago
What are some reasons to switch from nvm to Volta?
- adam_beck 5y ago
  It's faster and cross-platform (Windows/Linux/MacOS). Switching version managers is trivial. If you don't like it, just switch back in the time it takes to uninstall a binary.
  - pjerem 5y ago
    Last time I tried it, it totally broke my WebStorm setup (on Windows).
filmgirlcw 5y ago
+1 for Volta. Finally switched to it for my own setup this week and it’s just so much easier. Big, big fan.
joelkesler 5y ago
I have been watching Volta. It looks pretty great.
gizdan 5y ago
Better yet, use asdf. It supports more than just node. I manage go, node, python, terraform, direnv, and many more with it.
petepete 5y ago
Of the alternatives I like fnm the most. It's a single binary, blazing fast and just works how you'd expect it to.

jonchurch_ 5y ago

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 =]

errcorrectcode 5y ago
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."
joelkesler 5y ago
Author 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!

don-code 5y ago

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.

indigodaddy 5y ago
Is declarative related to (or maybe leads to) idempotency?
- kubanczyk 5y ago
  Declarativeness (vs imperativeness) is the property of a language. Whether it allows you to express the desired state, as opposed to a sequence of simple operations. Idempotency is the runtime behavior. You can absolutely write idempotent program using imperative language (case in point: chef and its recipe can be expressed as machine code, which is a very imperative language, yet it is idempotent when you run it).
  - indigodaddy 5y ago
    Thanks for this explanation!
emeraldd 5y ago
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...).

r-w 5y ago

This is fantastic!!! Also: no love for fish? ;)

joelkesler 5y ago
I haven’t reached that level of enlightenment yet :)
- couponsva 5y ago
  Thank you for this idea. Christmas is coming and this is a nice gift to get especially if you are too busy and forget to do shopping https://couponsva.com/store/macys https://couponsva.com/store/macys

xyzzy_plugh 5y ago

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.

chidog12 5y ago
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.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
joelkesler 5y ago
Author here: 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

spywhere 5y ago

I did the same with my dotfiles setup, but it's for my personal preferences. 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 https://github.com/spywhere/dotfiles

tomcam 5y ago
I think you should post this separately. It appears to of been painstakingly developed over a long time and has an array of options I would expect from a professional setup.
- spywhere 5y ago
  It definitely been working on for quite some time. I start working on it as a simple setup with just `Brewfile` for brew bundle, then adding custom comments to run grep + xargs to pipe to Aptitude / APK / package manager to install the same package for different platforms. I find myself constantly either in need of reinstalling the whole OS or setup my environment a lot, hence I need to make the setup flexible and various options to better reduce the time I spent manually install stuffs.
sirn 5y ago
Ha, I also have something similar[1], but I use a mix of profiles and flavors. I have two profiles: pkg for installing packages and user for configuring user profiles. Profiles are then broken down further with flavors: dev for development packages, desktop for desktop packages and configurations, and so on. I found it highly amusing that we're taking similar approaches for a lot of things: a wrapper function for sudo and fetch, and OS detection (especially the appending WSL suffix part). Mine is not as idempotent as yours, and having a per-package definition is still in my TODO list, though. [1]: https://github.com/sirn/dotfiles https://github.com/sirn/dotfiles

pkulak 5y ago

Do you still have to wait for all 12 gigs of xcode to download and extract, then agrees to terms before you can use git?

easton 5y ago
"xcode-select --install" grabs only the command line utilities included with Xcode (git, swift, clang, python3.8, etc), and it's only 400MB on my machine. That command has been there for a while, since Leopard or so, and Homebrew prompts you to run it before you continue with installing brew.
- TomatoTomato 5y ago
  Just typing `git` works too
- pkulak 5y ago
  Macports still says to download xcode in full first: https://guide.macports.org/#installing.xcode https://guide.macports.org/#installing.xcode Any idea why that is? Is it out of date?
  - saagarjha 5y ago
    It’s not required, unless you decide to install something that needs it. Most packages don’t need it at all these days.

easton 5y ago

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.

errcorrectcode 5y ago

Sorry, but configuration management supersedes setup scripts. This isn't interesting.

oplav 5y ago

defaults write com.apple.finder ShowPathbar -bool true 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.

shiloa 5y ago
I found Cmd+Shift+G in finder handy. It'll open a text box to type your desired path and supports tab completions.
GVRV 5y ago
You can open a finder window, press `Cmd + Shift + G` to navigate to a path easily.
unbanned 5y ago
This is where MS Windows really shines is window management. It sucks on a Mac and quickly feels cluttered.

Uptrenda 5y ago

I find this completely boring and un-newsworthy.

meabed 5y ago

Nice - i learned few tricks from there. for the mac setup, I have been using this for years and works well for me. https://github.com/geerlingguy/mac-dev-playbook https://github.com/geerlingguy/mac-dev-playbook

winrid 5y ago

I've found that using ansible works pretty well for setting up dev machines.

deleted 5y ago

[deleted]

thatguydidit 5y ago

https://github.com/geerlingguy/mac-dev-playbook https://github.com/geerlingguy/mac-dev-playbook a well loved and maintained ansible playbook for macs. Just FYI

joelkesler 5y ago
Thanks! I will take a look

setheron 5y ago

This script is a great pitch why Nix is the future. Using these scripts as a way to give "reproducible" build environments is just doomed.

jvolkman 5y ago

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.

burdiyan 5y ago
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.
- jvolkman 5y ago
  Ideally your IDE supports Bazel. There's a Bazel plugin for Intellij that works reasonable well for Java. We use python primarily, and while this plugin does support Python a bit, it's got some issues. So we wrote a bazel rule that builds a python virtualenv using Bazel dependencies and that bridges the gap to allow use of "legacy" tooling.
  - burdiyan 5y ago
    Nice! I was thinking about something like that too. E.g. building symlinks for all the deps into a local directory and use it as PYTHONPATH. I tried it with your example on GitHub and it worked. And then if all the developers are using something like direnv[1] this PYTHONPATH variable could easily be set for everyone. How do you manage dependencies for the fine-grained Bazel targets (like py_library)? Do you write them manually or using some language-specific tools like Gazelle? If you do use the tool, do you have anything in place to automate it? Couple years ago I had a pretty bad experience with people complaining about having to execute Gazelle manually. In my ideal world view I'd want to add an import statement in code and just run `bazel build`. So I ended having a wrapper that would run Gazelle before running Bazel all the time, but it slowed thing down quite a bit, because it was doing a lot of unnecessary work. [1]: https://direnv.net https://direnv.net

W0lf 5y ago

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.

bluedino 5y ago
I worked at a small Rails shop a long time ago. Everyone had their Mac setup differently (they each did the setup themselves), and nobody really knew how theirs was setup. Until something broke. Development domain names - some people used /etc/hosts, some people used pow, others used PassengerPane. For packages, a few people used Brew, some used MacPorts... In the end we went with a standard setup where I implemented things like rvm (we had both Rails 2 and Rails 3 apps). And even created a CentOS setup script which was as similar as possible.
akyoan 5y ago
"I cannot trust your competence as a developer if you can't build your compiler in assembly." These setups are useful because: - not everyone needs to start from scratch every time - they share one’s known-how through their configuration Even if I rarely use boilerplates and such, often they're good resources to see how a specific problem has been fixed. Also if they're done well they lower the barrier of entry considerably. See create-react-app where you can start developing something serious in React without starting from an empty index.html and glue everything together.
danjac 5y ago
A new developer of decent competence in your tech stack should be able to go from zero to first commit in a few hours. If that's not possible then you have a technical debt problem that's probably a smell for other issues in your code base. Sometimes the complexity is unavoidable - e.g. loading some large training data set or a complicated tool chain of some essential libraries - in which case you should automate away as much as possible in build scripts. Sometimes the setup complexity is due to poor maintenance - "we used Gulp 3 years ago, but switched to Webpack last year, and the frontend guys are trying out esbuild, but there's still stuff that's running under Webpack and we need Gulp for these couple old pages over there". Either way, there's no better way to crush the enthusiasm of a new hire than have them bogged down in your shitty install setup on their first day.

zingar 5y ago

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 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.

rcarmo 5y ago

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.

koirapoika 5y ago

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.

pkrumins 5y ago

I made something similar. Whenever I install a new workstation that runs Linux, I run this script: http://github.com/pkrumins/install-computer/blob/master/install.sh 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).