"default" isn't really a group, it's more the absence of one. With
Bundler, this means that a gem should be installed unconditionally,
regardless of which groups are specified. It doesn't really make sense
to allow these gems to be omitted from a bundlerEnv.
This wasn't really an issue until the latest minor release of Bundix
(2.4), because prior to then Bundix didn't emit group attributes, and so
this functionality of bundlerEnv wasn't really used. However, it is now
apparent that a better default for bundlerEnv would be to include all
gem groups by default, not just the default group. This matches the
behavior of Bundler, and makes more sense, because the default group
alone isn't necessarily useful for anything -- consider a Rails app with
production, development, and test groups. It has the additional benefit
of being backwards compatible with how this would have worked before the
Bundix update.
Suppose I have a Gemfile like this:
source "https://rubygems.org"
gem "actioncable"
gem "websocket-driver", group: :test
The gemset.nix generated by Bundix 2.4.1 will set ActionCable's groups
to [ "default" ], and websocket-driver's to [ "test" ]. This means that
the generated bundlerEnv wouldn't include websocket-driver unless the
test group was included, even though it's required by the default group.
This is arguably a bug in Bundix (websocket-driver's groups should
probably be [ "default" "test" ] or just [ "default" ]), but there's no
reason bundlerEnv should omit dependencies even given such an input --
it won't necessarily come from Bundix, and it would be good for
bundlerEnv to do the right thing.
To fix this, filterGemset is now a recursive function, that adds
dependencies of gems in the group to the filtered gemset until it
stabilises on the gems that match the required groups, and all of their
recursive dependencies.
I had to drop xorriso because it didn't seem to want to compile with it
any more, and had to add libopus as a build input because it wouldn't
compile without that.
It would be reasonable to have a Ruby program that depends on some other
program being in the PATH. In this case, the obvious thing to do would
be something like this:
bundlerApp {
# ...
buildInputs = [ makeWrapper ];
postBuild = ''
wrapProgram "$out/bin/foo" \
--prefix PATH : ${lib.makeBinPath [ dep ]}
'';
}
However, this doesn't work, because even though it just forwards most of
its arguments to `runCommand`, `bundlerApp` won't take a `buildInputs`
parameter. It doesn't even specify its own `buildInputs`, which means
that the `scripts` parameter to `bundlerApp` (which depends on
`makeWrapper`) is completely broken, and, as far as I can tell, has been
since its inception. I've added a `makeWrapper` build input if the
scripts parameter is present to fix this.
I've added a `buildInputs` option to `bundlerApp`. It's also passed
through to bundled-common because `postBuild` scripts are run there as
well. This actually means that in this example we'd end up going through
two layers of wrappers (one from `bundlerApp` and one from
bundled-common), but that has always been the case and isn't likely to
break anything. That oddity does suggest that it might be prudent to
not forward `postBuild` to bundled-common (or to at least use a
different option) though...
FWIW, as far as I can tell no package in nixpkgs uses either the
`scripts` or `postBuild` options to `bundlerApp`.
> WARNING: The next major version of capybara-webkit will require at
> least version 5.0 of Qt. You're using version 4.8.7.
I went to 5.9 instead of 5.11 because 5.11 doesn't currently build on
Darwin, whereas 5.9 can build on both Darwin and Linux, and is still
well within the >=5.0 requirement.
Allows for adding Perl libraries in the same way as for Python. Doesn't
really need to be a function, since there's only one perlPackages in
nixpkgs, but I went for consistency with the python plugin.
Why is qtmultimedia only needed on Darwin? Why does it only fix 5.9, not
5.11? These things I do not know. What I do know is that, for some
reason, this makes qt59.qtwebkit build on Darwin.
I think the reason it hasn't also fixed 5.11 might be something to do
with the version of qtmultimedia, but I don't know enough about Qt or
cmake to figure it out. The error when trying to build qt511.qtwebkit
(with or without these changes) is:
CMake Error at Source/cmake/OptionsQt.cmake:739 (find_package):
Could not find a package configuration file provided by "Qt5Multimedia"
(requested version 5.2.0) with any of the following names:
Qt5MultimediaConfig.cmake
qt5multimedia-config.cmake
Add the installation prefix of "Qt5Multimedia" to CMAKE_PREFIX_PATH or set
"Qt5Multimedia_DIR" to a directory containing one of the above files. If
"Qt5Multimedia" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
Source/cmake/WebKitCommon.cmake:50 (include)
CMakeLists.txt:137 (include)
-- Configuring incomplete, errors occurred!
See also "/tmp/nix-build-qtwebkit-5.212-alpha-01-26-2018.drv-0/source/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/nix-build-qtwebkit-5.212-alpha-01-26-2018.drv-0/source/build/CMakeFiles/CMakeError.log".
There's no reason `linkFarm` can't be used for symlinks in
subdirectories, except that currently it doesn't ensure the directory
of the link exists. This backwards-compatible change expands the utility
of the function.
Alyssa Ross