3 ms·
use it as an interactive shell first, not for shell scripts. also, why would any dependency of your projects at work be implicit? all dependencies should be ca
by onetom 5y ago
use it as an interactive shell first, not for shell scripts.
also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation.
at our company, we use shell.nix files to declare all of our dependencies, so everyone has the exact same software available on their development workstations.
it's not a completely trivial thing to do, but worth investing into it, to lower the chance of surprises, which will happen when you can afford them the least...
here is an example to get started:
```
with import (builtins.fetchTarball {
name = "nixos-unstable-on-2021-05-16";
url =
"https://releases.nixos.org/nixos/unstable/nixos-21.05pre289339.83d907fd760/nixexprs.tar.xz"; https://releases.nixos.org/nixos/unstable/nixos-21.05pre2893...
sha256 = "1kilrk0ipvldf4rrn6aq6v2bj2jfhbz33cjb9w9ngqmbmr2f94wd";
}) { };
let
project-jdk = jdk11;
clojure = callPackage ./deps/clojure { jdk11 = project-jdk; };
in mkShell rec {
buildInputs = [
coreutils
cacert
direnv
nixfmt
curl
jwt-cli
fd
python3
nodejs
(yarn.override { nodejs = nodejs; })
project-jdk
clojure
yaml2json
modd
devd
overmind
];
shellHook = ''
export LC_CTYPE="UTF-8" # so tar and rlwrap won't complain
'';
}
```
it shows how u would use your custom package (for clojure in our case) and how would u pin there state of the whole package repository to a specific point in time.
in the past I've used es, the extensible shell (https://wryun.github.io/es-shell/ https://wryun.github.io/es-shell/), this way, without bothering my colleagues with teaching them about it. they just git pull, press enter in a shell within the hour repo and direnv will pull down any new dependencies.
- rgoulter 5y ago> also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation. .... Nix. Because distributing software is hard, especially if things change. That's one big reason why Docker images will sometimes get used for development environments (like what VSCode supports). Nix is nice, and is a pretty good way of capturing those dependencies. But it's also difficult to customise, often lacking in documentation, and not used very widely. If you're not using something like Nix (i.e. most people), it's natural for dependencies to be quite implicit.
- onetom 5y agoI understand that the industry largely does not acknowledge how big of a problem implicit dependencies are, but since the OP is clearly aware of some issues with implicit dependencies, I was just surprised why so content with these issues. It clearly hinders the adoption of upcoming technologies at least in the mind of the OP. I'm not really an expert in the Nix expression language. Hasn't even finished reading the Nix pills, which is a very practical documentation, yet I could manage to extract a lot of benefit from that shell.nix template I've shared. I'm using Nix for 3+ years now. Because of this experience I do encourage others not to be afraid trying Nix. It gets better with every release. Docker is a halfway solution and because of its memory and storage requirements it often strains the average development workstations and internet connections.