The manual documents both bundlerEnv and bundlerApp as providing `env`
and `wrappedRuby` attributes on the resulting derivations. However only
bundlerEnv actually had these attributes. Update bundlerApp to provide
the same passthru that bundlerEnv does.
In case of the gem type 'git', nix-bundle-install.rb was called with
wrong path to the git checkout.
${src} does contain the sources, but not the newly generated .git dir,
which is created in the buildPhase of pkgs/development/ruby-modules/gem/default.nix
In some rare cases, this .git dir is needed at installPhase.
Note: on macOS, it works without this config. Testing on Ubuntu/Debian with the parent sha will produce an error about extconf.rb failing to find openssl/sha.h.
`digest-sha3` is a C-extension gem which fails to build on Nix because
it uses non-literals as format strings which is forbidden by the default
Nix hardening settings. There is a pull request to fix that ([1]), but
the gem seems to be abandoned.
This PR disables the "format" hardening for `digest-sha3`.
[1]: https://github.com/phusion/digest-sha3-ruby/pull/8
"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.
> /nix/store/r2vsi140pys7jnzyk0qz1fj9aji6sq40-ruby2.5.3-rb-readline-0.5.5/lib/ruby/gems/2.5.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:1097:in `<module:RbReadline>': HOME environment variable (or HOMEDRIVE and HOMEPATH) must be set and point to a directory (RuntimeError)
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.
This fixes the bug introduced by 8686b98612 which broke bundlerEnv
exprs when gemdir was a string (thus making gemset a string by
`gemset = gemdir + "/gemset.nix"`) which made it being treated as a
set.
Don't default `doCheck` to false,
and use the default set of phases
so the phases list does not need to be overriden
in order to add checkPhase or installCheckPhase.
This just defers to `fetchurl` for fetching.
Additionally, update the `nix-bundle-install.rb` script to handle gems
installed from a path, i.e. those with a `url` source.
Some parts of that script have been disabled in the `path` case
that likely shouldn't be, but cause errors and aren't necessary to get
`vagrant` to work.
Keep the `source` attrset distinct to prevent its entries from merging
with the top level attrs.
Since each type of source has a different set of entries for `source`,
this is the easiest way to keep them together.
This will pave the way for a new `url` type of source.
This is a mass-rebuild of many ruby packages,
notably those using `git` type sources.
This allows patching the gemset output by bundix from a default.nix
file, making it easier to perform updates since the bundix update no
longer has to be manually updated.
This release in a RC for gnupg-2.2. The main difference as far as
nixpkgs is concerned is that the binary `gpg2` is now called `gpg` and
`gpgv2` is called `gpgv`.
This update fixed all explicit use of `gpg2` and `gpgv2` across nixpkgs,
but there might be some packaged software that internally use `gpg2`
not handeled by this commit.
See http://lists.gnu.org/archive/html/info-gnu/2017-08/msg00001.html
for full release information
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
This fixes `fetchurl-force.nix` not being installed, which breaks
bundix for some gems.
E.g.
```
$ nix-build --argstr url https://rubygems.org/gems/nio4r-2.1.0.gem /nix/store/y6959dxal86l3alc0ryf7752prbbkzxg-bundix-2.2.0/lib/ruby/gems/2.3.0/gems/bundix-2.2.0/lib/bundix/fetchurl-force.nix
error: getting status of ‘/nix/store/y6959dxal86l3alc0ryf7752prbbkzxg-bundix-2.2.0/lib/ruby/gems/2.3.0/gems/bundix-2.2.0/lib/bundix/fetchurl-force.nix’: No such file or directory
```
Rainbow needs rake (a make analogue) as build dep. This builds an specific
version of rake for building rainbow.
Since rake is private to rainbow there shouldn't be any problems until rainbow
devs decide they need another rake version which is unlikely.
The bin stubs need to be built where there's access to /nix/store - so
it can't happen in a nix-shell run. Ergo, a shell.nix needs to be able
to signal to the build that all bins need to be built.
Original error:
$ nix-shell -p jekyll --command "jekyll new test"
Running bundle install in /private/tmp/test...
Bundler: There was an error while trying to write to
Bundler:
`/nix/store/l67429rhvrmr7c4c1msb7s8zjq4fx7ad-gemfile-and-lockfile/.bundle/config`.
Bundler: It is likely that you need to grant write permissions for
that path.
`usesGemspec` no longer required to trigger the "copy everything into
gemfile-and-lock" behavior. If the mainGem is referred to by path,
that's sufficient.
Without the adjustment I was not able to build scrypt. It was failing
because of missing symbols due to the parameter '-arch i386' being
appended to the clang calls.
From the website,
https://gitlab.com/mjwhitta/zoom
Zoom adds some convenience to ag/ack/grep by allowing you to quickly
open your search results in your editor of choice.
Also available as a ruby gem.
https://rubygems.org/gems/ruby-zoom
In addition to including the ruby-zoom tool, we also added a global
override for the ruby-terminfo gem to handle the ncurses build time
dependency.
Add `pname` attribute: if passed, the derivation name defaults to the
gem name + version and only expose the gem's bin.
Add `gemdir` attribute: gives a default lookup path for the Gemfile,
Gemfile.lock and gemset.nix.
Set the `meta.platforms' to `ruby.meta.platforms' by default.
* Manage patches in git
* Fixes the hook invocation to be more safe. Thanks @Mic92
* Install gems as user by default
* Install gem binaries with the /usr/bin/env shebang
* Fixes a bug where the passthru.libPath and passthru.gemPath would
point to the wrong directory
* Overhaul ruby version heuristics
If a gemspec has UTF-8 characters in it, ruby will fail loading it with
invalid multibyte char (US-ASCII)
This change forces the encoding to be correct, we assume everyone now
uses UTF-8.
For some reason `gem install` unsets the GEM_PATH environment variable
internally unless the install dir is provided. This in turn means that
if it invokes extconf.rb and extconf.rb depends on a gem available on
the GEM_PATH (like pkg-config for nokogiri) then it's not available in
that context.
Proof: d8293c4729/lib/rubygems/commands/install_command.rb (L151)
Blame: 9ea600c9c2
This is a hack that sets the :install_dir to where we would install
anyways (the GEM_HOME is the default installation destination).
bundler for example needs to have the GEM_HOME being passed trough to
function properly.
For gems that are loading content dynamically, or can use plugins, use
buildRubyGem.
For executables that are wrapped in their own sealed thing use
bundlerEnv.
