`"lua" + lua.luaversion + "-"` resolves to "lua51-" for both Lua
5.1 and LuaJIT packages. With this, LuaJIT packages instead get
`lua.name + "-"`, which currently resolves to "luajit-2.1.0-beta3-".
This makes it easy to distinguish the two in store paths etc.
The team behind ksonnet was aquired by VMware, and they decided to end
work on ksonnet:
From https://blogs.vmware.com/cloudnative/2019/02/05/welcoming-heptio-open-source-projects-to-vmware:
> Prior to the acquisition, Heptio had been shifting focus and resources
> away from ksonnet; with the acquisition, we felt it was the right time
> to rethink our investment in ksonnet. As a result, work on ksonnet will
> end and the GitHub repositories will be archived. It’s extremely
> difficult to step back from a project we have worked so hard on, but
> we’re excited about our new ideas and vision for changing how developers
> experience the Kubernetes and cloud native ecosystems.
unfortunately, some private headers making the logging hard to handle.
Specifically, os/activity.h that is included does not match what Qt5
is expected. This removes the activity logging (while keeping the
other logging methods) on macOS.
Fixes #63528
The team behind ksonnet was aquired by VMware, and they decided to end
work on ksonnet:
From https://blogs.vmware.com/cloudnative/2019/02/05/welcoming-heptio-open-source-projects-to-vmware:
> Prior to the acquisition, Heptio had been shifting focus and resources
> away from ksonnet; with the acquisition, we felt it was the right time
> to rethink our investment in ksonnet. As a result, work on ksonnet will
> end and the GitHub repositories will be archived. It’s extremely
> difficult to step back from a project we have worked so hard on, but
> we’re excited about our new ideas and vision for changing how developers
> experience the Kubernetes and cloud native ecosystems.
mergeInputs is now simply defined in terms of `concatLists` and
`catAttrs` instead of a more complicated `foldr`.
Note that the order of PATH has also changed. For example running the
following with nix-shell:
let
pkgs = import <nixpkgs> {};
shell1 = pkgs.mkShell {
buildInputs = [ pkgs.htop ];
};
shell2 = pkgs.mkShell {
buildInputs = [ pkgs.hello ];
};
shell3 = pkgs.mkShell {
inputsFrom = [ shell1 shell2 ];
buildInputs = [ pkgs.tree ];
};
in shell3
Results in the following PATH:
$ echo $PATH
...
/nix/store/yifq4bikf7m07160bpia7z48ciqddbfi-tree-1.8.0/bin:
/nix/store/vhxqk81234ivqw1a7j200a1c69k8mywi-htop-2.2.0/bin:
/nix/store/n9vm3m58y1n3rg3mlll17wanc9hln58k-hello-2.10/bin
...
Previously the order was:
/nix/store/n9vm3m58y1n3rg3mlll17wanc9hln58k-hello-2.10/bin
/nix/store/vhxqk81234ivqw1a7j200a1c69k8mywi-htop-2.2.0/bin:
/nix/store/yifq4bikf7m07160bpia7z48ciqddbfi-tree-1.8.0/bin:
I think the new order makes more sense because it allows to override
the PATH in the outermost mkShell.
Running the following expression with nix-shell:
let
pkgs = import <nixpkgs> {};
shell1 = pkgs.mkShell {
shellHook = ''
echo shell1
'';
};
shell2 = pkgs.mkShell {
shellHook = ''
echo shell2
'';
};
shell3 = pkgs.mkShell {
inputsFrom = [ shell1 shell2 ];
shellHook = ''
echo shell3
'';
};
in shell3
Will now results in:
shell2
shell1
shell3
Note that packages in the front of inputsFrom have precedence over
packages in the back. The outermost mkShell has precedence over all.
