<clever>
LnL: it would probably need builtins.fetchGit, and even that has some issues, which ive reported
<clever>
though it doesnt really work on git repos
<clever>
[clever@amd-nixos:~]$ nix-instantiate ~/apps/nixpkgs --eval -A lib.nixpkgsVersion
<clever>
"18.09pre-git"
<clever>
tilpner: there is also nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
<clever>
yep
<clever>
callPackage adds an .override function to everything it loads
<clever>
.override
<clever>
thats already been callPackage'd
<clever>
_null_: how did you run callPackage?
<clever>
disasm: sent a PM as well
<clever>
disasm: only thing i can see as an issue in your PR is the lack of enableParallelBuilding = true;, its only using 1 core when i test the build
<clever>
but i have no idea how deterministic pixz is, and i havent been able to get build-repeat to work on nix
<clever>
the biggest difference is runtime (5m vs 1m20) and output size (118mb vs 129mb)
<clever>
disasm: one piece of input i'm looking for, is if i should keep the default at xz, or change the default to pixz
<clever>
i'll have a deeper look
<clever>
already skimmed over your description
<clever>
disasm: heh, we opened PR's within 7 seconds of eachother
2018-03-17
<clever>
i used gosmore many years ago
<clever>
go away windows, nobody wants you :P
<clever>
symphorien: you could also just throw a prePatch hook in, to dos2unix the entire project!
<clever>
so i can see all the unprintable things!
<clever>
it also renders tabs, and spaces at the end of lines
<clever>
symphorien: i have my vim configured to render the \r's if the file is mixed
<clever>
symphorien: ahh, yeah, things get ugly fast when half the tool uses \n and half uses \r\n
<clever>
and apple/default.nix doesnt have defaults for these params, so the import fails
<clever>
{ config, lib, ... }:
<clever>
so now you have an apple channel, that is based on the result of import <nixos-hardware/apple/default.nix> {}
<clever>
and it finds nixos-hardware/apple/default.nox
<clever>
because nixos-hardware/default.nix doesnt exist, it goes one level deeper
<clever>
that name is then added to nix-env, so you can nix-env -iA <name>.hello
<clever>
and nix-env will recursively search ~/.nix-defexpr/ until it either finds a <name>/default.nix or a <name>.nix
<clever>
when you added that channel, it created ~/.nix-defexpr/channels/nixos-hardware
<clever>
but those are nixos modules, that expect a config argument
<clever>
it then tries to load every single one of those, and treat its default.nix as a channel
<clever>
called 4810t, n990, apple, asus ....
<clever>
due to the layout of nixos-hardware, and the lack of a default.nix at the root, nix-env thinks you have 15 channels
<clever>
yeah
<clever>
i suspect it will be fixed by just adding a default.nix in the root of the project, that contains { ... }: {}
<clever>
but -iA nixos.hello tells it to use the hello package in the nixos channel, so it can skip nixos-hardware entirely
<clever>
it also wastes a ton of ram and cpu reading every package under the sun
<clever>
and it fails when loading the nixos-hardware channel
<clever>
the problem, is that -i will search the .name attribute of every package, on every channel
<clever>
fl3: -iA will still work, and its better anyways
<clever>
!-A
<clever>
fl3: ah, i suspect those directions just break nix-env -qa, and nobody noticed
<clever>
fl3: it sounds more like your default.nix is a nixos module, so it makes sense why it fails
<clever>
fl3: nix-env expects the default.nix in a channel to have default arguments, and to return a package set
<clever>
coconnor: for nix1 its /nix/var/nix/binary-cache-v3.sqlite*
<clever>
coconnor: nix will recreate it automatically any time its missing
<clever>
fl3: what command did you run, and can you gist the file you ran it on?
<clever>
coconnor: if you delete that path, it will have to re-query every .narinfo, and discover that things arent there anymore
<clever>
coconnor: the client uses this database to keep track of the .narinfo so it doesnt have to re-query it
<clever>
~/.cache/nix/binary-cache-v5.sqlite*
<clever>
coconnor: yeah, is the client nix1 or nix2?
<clever>
coconnor: you likely ran a garbage collection and deleted that path
<clever>
coconnor: which binary cache?
<clever>
ottidmes: yeah, you cant use mylib for imports, thats the main restriction
<clever>
then you can { config, pkgs, lib, mylib, ... }:
<clever>
ottidmes: if you want something custom you could do _module.args.mylib = ...
<clever>
ottidmes: ahh, yeah
<clever>
ottidmes: that should just work if you { config, pkgs, lib, ... }: and maybe with lib;
<clever>
ottidmes: what are you trying to do?
<clever>
so pkgs cant depend on the result of config
<clever>
it needs to scan all imports recursively, to find nixpkgs.config, to create pkgs
<clever>
coconnor: i think that only applies to the imports attribute
<clever>
so they have to be in a "single directory"
<clever>
i think the problem, is that ghc cant accept multiple flags for where to find deps?
<clever>
for c based compilers, nixos just appends -I flags to an env var, and the gcc wrapper forces those in, so an app is free to clear $CFLAGS and still get the cflags
<clever>
which is very different from how nixos handles gcc/clang
<clever>
it will also buildEnv all of the libraries, and their deps, into a single directory
<clever>
then runs the real ghc
<clever>
coconnor: ghcWithPackages creates a bash script that sets export NIX_GHCPKG='/nix/store/0pv3ghl8087f0dhw9k7475299n8hqfii-ghc-8.2.2-with-packages/bin/ghc-pkg' and a few other vars
<clever>
ghc is a weird exception, due to how it works in nix
<clever>
so its more suited to just run a program, and not build things
<clever>
the biggest difference i can see, is that `nix run` doesnt get normal compile-time packages or handle setup hooks
<clever>
coconnor: that wont include a ghc, and ghc wont be modified to look for it
<clever>
mpickering: where it splits the string at the .'s and calls functions at every step
<clever>
mpickering: i suspect its doing the same fun stuff as -A with nix-build and nix-env
<clever>
mpickering: pkgs, nixpkgs, and nixos all fail
<clever>
slack1256: but it dosnt import nixpkgs on its own
<clever>
slack1256: the parens convince it that its an expression and not an attr path
<clever>
slack1256: ghc-pkg list now shows lens
<clever>
slack1256: its more verbose then i was expecting, but this appears to be working
<clever>
$ nix run '(with import <nixpkgs> {}; haskellPackages.ghcWithPackages (p: with p; [ lens ]))'
<clever>
error: undefined variable 'haskellPackages' at (string):1:2
<clever>
$ nix run '(haskellPackages.ghcWithPackages (p: with p; [ lens ]))'
<clever>
infinisil: ah, i see
<clever>
ottidmes: its also at pkgs.lib
<clever>
infinisil: yeah, id have to look at what other distros do to know what can hapen there
<clever>
infinisil: ah, then they are going out of their way to source it twice, and make the 2nd one a no-op, lol
<clever>
yep
<clever>
infinisil: if it runs anything like a window manager or another progream in the background
<clever>
infinisil: nixos already sources .xprofile, before it runs .xsession