I have three exceptions to this: Vim (my editor of choice), dotfiles (which I store in a git repository and put in place using stow, installed via a simple bash script), and Vagrant, so I can do development testing against a VM.
As Docker matures, I may use it in place of Vagrant, but it's not ready to fill the same role quite yet.
Yes! A new machine is a great time to run a garbage collection cycle on my tools.
That said, I'm not a huge fan of Docker's feature churn; having to re-install, reconfigure, and re-learn tooling that is central to my workflow every other month gets old pretty quickly.
Right now I use a bash script I wrote to deploy my dotfiles into ~/, via symlink, including renaming existing files (after prompting the user).
I get what you mean about using that opportunity to do some spring cleaning. I find I need to do that to my Vim installation periodically too. I'll add a new plugin that looks like it will be useful, or add something for a new language or template system, then not use it enough to justify it.
Same. The core tools and libraries I use change more often than my development machine so when switching to a new machine it's a fun time to reassess what I need to install so I'm not carrying any baggage. I think the time automating the installation would be a net loss given how much I'd need it.
The setup required for building projects that I work on are automated using things like Vagrant so outside of that I only really need a few tools anyways.
Lazy comma usage. Come on!
It's actually a collaborative repository, so that both of us in our company can improve the computer configuration, install new tools or language runtimes, etc etc.
The shared configuration has stuff like: our user accounts and public SSH keys; local mailer setup; firewall; conf for X/bash/emacs/ratpoison/tmux; list of installed packages (including Chromium, mplayer, nethack, etc); fonts and keymaps; various services (nssmdns, atd, redis, ipfs, tor, docker, ssh agent, etc); some cron jobs; a few custom package definitions; and some other stuff.
In Emacs, I use "use-package" for all external package requirements so that when I start the editor it installs all missing packages from ELPA/MELPA.
Aside from dealing with the binary WiFi blob this Dell computer demands, reinstalling was a pleasure.
For the development itself I'm either shipping my entire config (.vimrc for example) or use systems like spacemacs, sublimious or proton that only need 1 single file to re-install the entire state of the editor.
The install script itself [1] is then symlinking everyhing into place and executes stuff like pip install -r ~/.dotfiles/pip/packages.txt.
It takes a bit of effort to keep everything up to date but I'm never worried of loosing my "machine state". If I go to a new machine all I have to do is clone my dotfiles, execute install.sh and I have everything I need.
On servers I am using saltstack [2], a tool like puppet, ansible and friends, to ensure my machines are in the exact state I want them to be. I'm usually using the serverless version and push my states over SSH to them.
[0]: https://github.com/Homebrew/homebrew-bundle
[1]: https://github.com/dvcrn/dotfiles/blob/master/install.sh
My head spins with these tools and every time I pick one I seem to eventually run into a road block that is a no-go. The most recent effort was ansible and the no-go was its strict dependency on python2.7.
The yaml makes it very easy to understand even if I come back to a state after months. It's just a list of things that should happen with a few template tags sprinkled in.
Not saying salt is better than puppet or friends. It's purely based on preference. I can't say anything to chef or ansible since I never tried them. Salt has a crazy active community and while there are things I don't like about it like the "name" of a state, it's still doing it's job just fine so I sticked with it.
(however, from my experience salt and ansible stay readable because they're yaml and not arbitrary code/DSL, whereas chef "recipes" are ruby and usually devolve into complex programs if you're not careful)
I created a set of Debian packages that depend on suites of packages I need. I download and install "josh-apt-source", which installs the source in /etc/apt/sources.list.d and the key in /etc/apt/trusted.gpg.d/ , then "apt update" and "apt install josh-core josh-dev josh-gui ...". That same source package also builds configuration packages like "josh-config-sudoers".
You created a Debian installation of yourself. Simply run "apt install josh-core josh-dev...", and Josh will be ready to start developing on the system whenever he is connected.
Setting up conemu to autorun a script when opening a cmd, as well as configuring my bash profile. At work (more osx these days), I usually email myself the latest, and have a ~/.auth file thats 700 that I can source in to init my proxy settings (including ssh+corkscrew)... Allows me to only have to edit credentials in one location.
Or I have to install the PPAs before I can use the metapackage (which kind of defeats the idea of using a metapackage instead of a script)?
There's a learning curve, and plenty of 'where did my afternoon go?' rabbit holes you can lose yourself in. But the upside is that you can have consistent, repeatable, and rapid builds, with modularity as a bonus.
Don't be afraid with any of these kinds of tools to brute force complex components if you're in a hurry - ie. ignore the pure / idiomatic way, and use the tool's primitives to dump a shell script on a remote box and then run it.
Also, +1 for using CM to set your workstation back up, I really need to get around to writing some Puppet manifests to do that for mine
Package customizations like a .vimrc is also handled by nix (I recently blogged about how I do this: https://www.mpscholten.de/nixos/2016/05/26/sharing-configura...).
The shell scripts together with the package customizations (e.g. my custom vimrc) are managed by git.
- System-wide packages, systemd services, users, cronjobs, etc. are managed by /etc/nixos/configuration.nix
- My user profile has one package installed, which depends on all of the tools I want to be generally available (emacs, firefox, etc.). By using a single meta-package like this, I can manage it using git and it makes updates/rollbacks easier
- Each project I work on maintains its own lists of dependencies (either directly in a .nix file, or converted automatically from other formats like .cabal), which are brought into scope by nix-shell
- I also have a bunch of scripts which use nix-shell shebangs, so their dependencies are fetched when invoked, and available for garbage collection once they're finished
# ~/.nixpkgs/config.nix
{
packageOverrides = defaultPkgs: with defaultPkgs; {
# To install below "pseudo-package", run:
# $ nix-env -i all
# or:
# $ nix-env -iA nixos.all
all = with pkgs; buildEnv {
name = "all";
paths = [
fpp wget iterm2 jekyll
ghc ruby nodejs composer php
];
};
};
}
Unfortunately I don't have a public GH repo I can point at as I don't want to expose everything I use to the internet. However the principle is the same as provisioning servers with ansible.
The only thing different I do is I use GPG keys to decrypt and untar things like thunderbird profiles rather than using Ansible vault. I restore GPG keys + SHH keys from offline, encrypted USB backups.
Check it out if you haven't already.
On OSX, this is a no-brainer with brew[1] and brew cask[2]
# On my old mac
$ brew list
$ brew cask list
brew install npm
brew install zsh
brew cask install sublime-text
brew cask install google-chrome
brew cask install intellij-idea
Protip: "brew list" will list all installed packages, including dependencies, which you might not want. What you probably want is "brew leaves", where it lists all installed packages that are not dependencies of another installed package.
This makes a difference in cases where a dependency is no longer needed in the latest version.
On a related note, why does the majority of package managers make the common and simple task of "list all manually installed packages" so incredibly hard?
For a fun brain twister, try to list all the manually installed packages on your system by just reading the man pages and no internet. Ubuntu is nightmare mode for this challenge.
pacman -Qe
> brew
That right there is irony. You intended to give good advice about using reliable methods for installing software, then immediately recommend the Devils ass crack of package management tools.
[0] https://github.com/svaksha/yaksha/blob/master/yksh/apt-debia...
[1] https://github.com/svaksha/yaksha#2-folders
1. Install NixOS
2. Copy configuration.nix*
3. Copy dotfiles
4. # nixos-rebuild switch
5. Enjoy your old setup on new hardware--no secret sauce needed!
*A hardware-configuration.nix should have been generated by the installer. By default this is sourced by configuration.nix, in which case configuration.nix shouldn't need editing.
I have never used Guix/GuixSD but have heard good things about it. Behind the scenes it uses the Nix package manager and offers a subset of Nix packages licensed as free software. Whereas Nix/NixOS uses the Nix expression language, Guix/GuixSD uses a Guile Scheme front-end. I've heard the Guix CLI is quite nice and a bit more polished than Nix's but Nix is currently in the process of overhauling the CLI. See [1] for a more detailed comparison.
Both of these projects have very active development but don't have the volume of listings as you would find in e.g. AUR or the Debian repos. That said, I've been pleased and actually surprised at just how many packages exist. If you can't find what you want, contributing new packages isn't too hard (often just a case of finding something similar in the repos and changing the relevant values). You can check the current Nix [2] and Guix [3] packages here to see if enough of your needs are covered before giving one of them a try.
[0] http://grosskurth.ca/bib/2006/dolstra-thesis.pdf
[1] http://sandervanderburg.blogspot.com/2012/11/on-nix-and-gnu-...
For awhile I did maintain a windows batch script that installed things off of a share at work. I was dealing with pre-release Windows 8, and wiped frequently for upgrades. Even that probably wasn't worth it, but I didn't have a second machine at the time, and wanted to run it overnight instead of blocking my ability to work.
Once you've set up a box-script, you may run it on a freshly installed windows, go to lunch, and when you return everything's set up.
From there, I'll setup a ~/bin directory with various scripts as utilitarian. I may source some of them in my profile script.
----
Windows Git for Windows, Git Extensions, ConEmu, Visual Studio (Pro or Community, depending on environment), VS Code. I should look into chocolatey, but admit I haven't. NVM for windows.
----
Linux/Ubuntu generally apt, and ppa's as needed.
----
FYI: I keep my ~/bin symlinked under dropbox, as I tend to use the same scripts in multiple places. I will separate ~/bin/win, ~/bin/osx and ~/bin/bash, and have them in the path in appropriate order... linux/bash being default. I'll usually use bash in windows these days too, and set my OSX pref to bash. It's the most consistent option for me, even with windows /c/...
https://github.com/arianitu/setup-my-environment/blob/master...
The ansible script also links to my dotfiles, which can be found at:
Homebrew and Homebrew Cask on OS X handle at least 90% of what I want to install.
Is there a way to stop it? (installable on a fresh system? I've been experimenting with reformatting, so that's not a problem)
Edit: AFAIK .DS_Store is only created when you use Finder. In the past couple of years I've only used the Finders to drag'n drop stuff between ~/Desktop and ~/Downloads, terminal for the rest, so .DS_Store files might not be a problem in practice.
Edit2: Google helps answer your original question http://stackoverflow.com/questions/18015978/how-to-stop-crea...
I find it so surprising that there's no way to disable this.
Setting up tools is quick and easy:
1. Install Nix
2. Copy my config to ~/.nixpkgs/config.nix
3. Run "nix-env -i all"
In the future I'd like to try NixOS for managing OS X but it seems rather immature at this point for people that want stuff to Just Work primarily.
So if I need to start a project or rebuild a system to do a project I can generally use the project itself as guidance on what to install. After two or three builds I have usually cleared all the dependency hurtles. The only thing that really breaks down is not having your dotfiles available, but for me those are backed up/in SCM.
If you are familiar with building projects from scratch it becomes a lot easier to understand dependencies and grow the system to what it needs to be, and with VMs it is that much easier to start with a blank slate that you are capable of blowing away and not even trouble secondary workflows.
I still like ansible as a layer on top of AMI images when I spin projects up in the cloud though. I don't want to have to go install iotop when I want to use it, I want to just know that my tools are present and ready to go. But I consider this a different type of machine from my dev hosts.
As I see it, the best solution on a dev machine is to make it easy to install software I might need in future. That means having a package manager available and access to my preferred configuration. On linux I just need my dotfiles repo available on the box, on windows I also need chocolatey installed.
RPM's are insanely easy to create, and the work helps with deployment/version tracking on the end machine. For example I have an .spec that downloads a given version of codeIgniter, unzips it, tweaks some permissions, and then rolls it into an RPM and tosses it into a network accessible repo. The RPM has a pretty complete list of dependencies, so they automatically get pulled in.
So my devel script looks something like:
cat <<EOF
"EOF" > /etc/yum.repos.d/local-repo.repo
[local-repo]
name=local-repo
baseurl=http://xxxx
enabled=1
gpgcheck=...
EOF
PACKAGES="codeigniter otherstuff"
for PKG in $PACKAGES; do
sudo yum install -y $PKG;
doneI do a really fresh/clean install. I install tools as I need them and find myself leaving tools behind often and trying things out. I get setup on new machines pretty often: whether I installed a new linux distro on my chromebook, finally dual-booting Linux on my PC, or just setting up a dev VM.
Anyways, I recently abandoned using Tmux because I prefer using i3 as my window manager and it works for me much better because now I can not only tile terminal windows but also other utilities.
I've also moved on from using CMDer straight to using ConEmu on my Windows machine. Every reinstall is basically doing inventory of my tools.
Obviously, I keep a repo of dotfiles and other settings files.
https://github.com/Corsaair/redtamarin/wiki/DeveloperEnviron...
The Windows part have a Batch script setup to automate the install of cygwin, apt-cyg, wpkg, etc.
It is very specific to the Redtamarin project, compiling C++, compiling Java, compiling AS3 to bytecode, etc.
there are also other doc for hardware setup, SSH to/from Windows, running "remote" build from the LAN, etc.
but the setup should work for about anything, comments to improve it welcome :)
Our current system is built on a combination of VM templates and documentation for the devs to set up their own build machines manually. Anything that I can't containerize will be stuck there, too.
I haven't reinstalled in a long time so the install script might be broken though
Well, personally, I made my own project somewhat similar to the one I linked to but mine wasn't that savvy. Plus mine also installed stuff from npm (linters mostly), ruby-gems (jekyll blog), pip and grabbed some sources and compiled them and symlinked them to proper places using GNU Stow.
PS: He's the developer of Paper GTK Theme.
I have my configurations on a version controlled puppet repository. This helped a lot, and I'd recommend anybody to forget /etc versioning, and use a proper configuration control system even when it's not exactly a requirement. I'm about to ditch my /etc backups now.
A certain source of pain is software that must be kept up to date. I have Firefox and GHC on this category. Both hurt, but it's not worth it to repackage them.
This is my Ansible repo for reference: https://gitlab.com/edgard/ansible-ubuntu
And dotfiles: https://gitlab.com/edgard/dotfiles
https://github.com/vmorgulys/sandbox/blob/master/stackcity/t...
It's a big list of "apt-get -y install".
Installing dev tools on OS X are a matter of minutes then, because everything else comes with the Vagrant box.
Edit: I'm a web dev guy.
/etc/popularity-contest.conf has the same timestamp, so I'm curious whether Ubuntu (or Debian) keep any statistics on the lifetime of a system.
https://github.com/ianmiell/shutit-home-server/blob/master/S...
it's platform independent and automates the install of everything I need.
sudo apt-get install emacs emerge vimhttps://github.com/jwiegley/use-package
So my .emacs/init.el looks like
(use-package helm-projectile
:ensure t
:config (helm-projectile-on)
)This has happened twice.
This upgrade cycle magit (my main reason for using emacs in the first place) broke all my muscle memory and added a ton of featurea I don't want or use.
I wish I could just freeze emacs development...without getting left behind when I want to install a new package... oh well...
Dotfiles are stored in Dropbox, too, which is handy for keeping zsh and Sublime synced.
Use VMs or containers for local simulation of your deployment targets.
2. Install git.
3. Check out the complete, working development environment and run its Vagrantfile.