nixpkgs/pkgs/development/ruby-modules/gem-config/default.nix

239 lines
5.9 KiB
Nix
Raw Normal View History

# The standard set of gems in nixpkgs including potential fixes.
#
# The gemset is derived from two points of entry:
# - An attrset describing a gem, including version, source and dependencies
# This is just meta data, most probably automatically generated by a tool
# like Bundix (https://github.com/aflatter/bundix).
# {
# name = "bundler";
# version = "1.6.5";
# sha256 = "1s4x0f5by9xs2y24jk6krq5ky7ffkzmxgr4z1nhdykdmpsi2zd0l";
# dependencies = [ "rake" ];
# }
# - An optional derivation that may override how the gem is built. For popular
# gems that don't behave correctly, fixes are already provided in the form of
# derivations.
#
# This seperates "what to build" (the exact gem versions) from "how to build"
# (to make gems behave if necessary).
2015-10-21 18:48:56 +01:00
{ lib, fetchurl, writeScript, ruby, kerberos, libxml2, libxslt, python, stdenv, which
2015-07-08 23:10:07 +01:00
, libiconv, postgresql, v8_3_16_14, clang, sqlite, zlib, imagemagick
2015-01-25 21:01:48 +00:00
, pkgconfig , ncurses, xapian, gpgme, utillinux, fetchpatch, tzdata, icu, libffi
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
, cmake, libssh2, openssl, mysql, darwin, git, perl, gecode_3, curl
, libmsgpack, qt48, libsodium, snappy, libossp_uuid, lxc
2016-09-21 13:29:12 +01:00
}@args:
let
v8 = v8_3_16_14;
2014-10-28 04:16:14 +00:00
in
2014-10-28 04:16:14 +00:00
{
bundler = attrs:
let
templates = "${attrs.ruby.gemPath}/gems/${attrs.gemName}-${attrs.version}/lib/bundler/templates/";
in {
# patching shebangs would fail on the templates/Executable file, so we
# temporarily remove the executable flag.
preFixup = "chmod -x $out/${templates}/Executable";
postFixup = ''
chmod +x $out/${templates}/Executable
# Allows to load another bundler version
sed -i -e "s/activate_bin_path/bin_path/g" $out/bin/bundle
'';
};
2016-03-21 11:01:37 +00:00
capybara-webkit = attrs: {
2016-04-17 21:35:04 +01:00
buildInputs = [ qt48 ];
2016-03-21 11:01:37 +00:00
};
2015-01-25 21:01:48 +00:00
charlock_holmes = attrs: {
2015-04-16 00:24:04 +01:00
buildInputs = [ which icu zlib ];
2015-01-25 21:01:48 +00:00
};
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
dep-selector-libgecode = attrs: {
USE_SYSTEM_GECODE = true;
postInstall = ''
installPath=$(cat $out/nix-support/gem-meta/install-path)
sed -i $installPath/lib/dep-selector-libgecode.rb -e 's@VENDORED_GECODE_DIR =.*@VENDORED_GECODE_DIR = "${gecode_3}"@'
'';
};
eventmachine = attrs: {
buildInputs = [ openssl ];
};
2015-01-25 21:01:48 +00:00
ffi = attrs: {
buildInputs = [ libffi pkgconfig ];
};
2015-01-22 01:33:19 +00:00
gpgme = attrs: {
buildInputs = [ gpgme ];
};
2016-05-04 23:41:44 +01:00
hitimes = attrs: {
buildInputs =
stdenv.lib.optionals stdenv.isDarwin
[ darwin.apple_sdk.frameworks.CoreServices ];
};
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
# note that you need version >= v3.16.14.8,
# otherwise the gem will fail to link to the libv8 binary.
# see: https://github.com/cowboyd/libv8/pull/161
2014-10-28 04:16:14 +00:00
libv8 = attrs: {
buildInputs = [ which v8 python ];
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
buildFlags = [ "--with-system-v8=true" ];
2015-01-22 01:33:19 +00:00
};
msgpack = attrs: {
buildInputs = [ libmsgpack ];
};
mysql = attrs: {
buildInputs = [ mysql.lib zlib openssl ];
};
2015-01-25 21:01:48 +00:00
mysql2 = attrs: {
buildInputs = [ mysql.lib zlib openssl ];
2015-01-25 21:01:48 +00:00
};
2015-01-22 01:33:19 +00:00
ncursesw = attrs: {
buildInputs = [ ncurses ];
buildFlags = [
"--with-cflags=-I${ncurses.dev}/include"
"--with-ldflags=-L${ncurses.out}/lib"
2015-01-22 01:33:19 +00:00
];
2014-10-28 04:16:14 +00:00
};
2014-10-28 04:16:14 +00:00
nokogiri = attrs: {
buildFlags = [
"--use-system-libraries"
"--with-zlib-dir=${zlib.dev}"
"--with-xml2-lib=${libxml2.out}/lib"
"--with-xml2-include=${libxml2.dev}/include/libxml2"
"--with-xslt-lib=${libxslt.out}/lib"
"--with-xslt-include=${libxslt.dev}/include"
"--with-exslt-lib=${libxslt.out}/lib"
"--with-exslt-include=${libxslt.dev}/include"
2015-01-22 03:38:29 +00:00
] ++ lib.optional stdenv.isDarwin "--with-iconv-dir=${libiconv}";
2014-10-29 01:16:02 +00:00
};
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
patron = attrs: {
buildInputs = [ curl ];
};
2014-10-29 01:16:02 +00:00
pg = attrs: {
buildFlags = [
"--with-pg-config=${postgresql}/bin/pg_config"
];
};
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
puma = attrs: {
buildInputs = [ openssl ];
};
2016-06-16 18:33:12 +01:00
rbnacl = spec: {
postInstall = ''
sed -i $(cat $out/nix-support/gem-meta/install-path)/lib/rbnacl.rb -e "2a \
RBNACL_LIBSODIUM_GEM_LIB_PATH = '${libsodium.out}/lib/libsodium.${if stdenv.isDarwin then "dylib" else "so"}'
"
'';
};
2014-10-29 01:16:02 +00:00
rmagick = attrs: {
buildInputs = [ imagemagick pkgconfig which ];
2014-10-29 01:16:02 +00:00
};
ruby-lxc = attrs: {
buildInputs = [ lxc ];
};
ruby-terminfo = attrs: {
buildInputs = [ ncurses ];
buildFlags = [
"--with-cflags=-I${ncurses.dev}/include"
"--with-ldflags=-L${ncurses.out}/lib"
];
};
2015-01-25 21:01:48 +00:00
rugged = attrs: {
buildInputs = [ cmake pkgconfig openssl libssh2 zlib ];
};
scrypt = attrs:
if stdenv.isDarwin then {
dontBuild = false;
postPatch = ''
sed -i -e "s/-arch i386//" Rakefile ext/scrypt/Rakefile
'';
} else {};
sequel_pg = attrs: {
buildInputs = [ postgresql ];
};
2016-09-21 13:29:12 +01:00
snappy = attrs: {
buildInputs = [ args.snappy ];
};
2014-10-29 01:16:02 +00:00
sqlite3 = attrs: {
buildFlags = [
2015-10-13 21:30:30 +01:00
"--with-sqlite3-include=${sqlite.dev}/include"
"--with-sqlite3-lib=${sqlite.out}/lib"
2014-10-28 04:16:14 +00:00
];
};
2015-01-22 01:33:19 +00:00
sup = attrs: {
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
dontBuild = false;
2015-01-22 01:33:19 +00:00
# prevent sup from trying to dynamically install `xapian-ruby`.
postPatch = ''
cp ${./mkrf_conf_xapian.rb} ext/mkrf_conf_xapian.rb
2015-01-22 01:33:19 +00:00
substituteInPlace lib/sup/crypto.rb \
--replace 'which gpg2' \
'${which}/bin/which gpg2'
2014-10-28 04:16:14 +00:00
'';
2015-01-22 01:33:19 +00:00
};
2015-10-21 18:48:56 +01:00
timfel-krb5-auth = attrs: {
buildInputs = [ kerberos ];
};
2015-01-22 01:33:19 +00:00
therubyracer = attrs: {
2014-10-28 04:16:14 +00:00
buildFlags = [
2015-01-22 01:33:19 +00:00
"--with-v8-dir=${v8}"
"--with-v8-include=${v8}/include"
2014-10-28 04:16:14 +00:00
"--with-v8-lib=${v8}/lib"
];
};
2015-01-22 01:33:19 +00:00
2016-06-16 10:43:21 +01:00
typhoeus = attrs: {
buildInputs = [ curl ];
};
2015-01-25 21:01:48 +00:00
tzinfo = attrs: {
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
dontBuild = false;
2015-01-24 22:59:01 +00:00
postPatch = ''
substituteInPlace lib/tzinfo/zoneinfo_data_source.rb \
2015-01-25 21:01:48 +00:00
--replace "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
2015-01-24 22:59:01 +00:00
'';
};
2016-11-21 12:41:05 +00:00
uuid4r = attrs: {
buildInputs = [ which libossp_uuid ];
};
2015-01-24 22:59:01 +00:00
2015-01-22 01:33:19 +00:00
xapian-ruby = attrs: {
# use the system xapian
ruby: new bundler infrastructure This improves our Bundler integration (i.e. `bundlerEnv`). Before describing the implementation differences, I'd like to point a breaking change: buildRubyGem now expects `gemName` and `version` as arguments, rather than a `name` attribute in the form of "<gem-name>-<version>". Now for the differences in implementation. The previous implementation installed all gems at once in a single derivation. This was made possible by using a set of monkey-patches to prevent Bundler from downloading gems impurely, and to help Bundler find and activate all required gems prior to installation. This had several downsides: * The patches were really hard to understand, and required subtle interaction with the rest of the build environment. * A single install failure would cause the entire derivation to fail. The new implementation takes a different approach: we install gems into separate derivations, and then present Bundler with a symlink forest thereof. This has a couple benefits over the existing approach: * Fewer patches are required, with less interplay with the rest of the build environment. * Changes to one gem no longer cause a rebuild of the entire dependency graph. * Builds take 20% less time (using gitlab as a reference). It's unfortunate that we still have to muck with Bundler's internals, though it's unavoidable with the way that Bundler is currently designed. There are a number improvements that could be made in Bundler that would simplify our packaging story: * Bundler requires all installed gems reside within the same prefix (GEM_HOME), unlike RubyGems which allows for multiple prefixes to be specified through GEM_PATH. It would be ideal if Bundler allowed for packages to be installed and sourced from multiple prefixes. * Bundler installs git sources very differently from how RubyGems installs gem packages, and, unlike RubyGems, it doesn't provide a public interface (CLI or programmatic) to guide the installation of a single gem. We are presented with the options of either reimplementing a considerable portion Bundler, or patch and use parts of its internals; I choose the latter. Ideally, there would be a way to install gems from git sources in a manner similar to how we drive `gem` to install gem packages. * When a bundled program is executed (via `bundle exec` or a binstub that does `require 'bundler/setup'`), the setup process reads the Gemfile.lock, activates the dependencies, re-serializes the lock file it read earlier, and then attempts to overwrite the Gemfile.lock if the contents aren't bit-identical. I think the reasoning is that by merely running an application with a newer version of Bundler, you'll automatically keep the Gemfile.lock up-to-date with any changes in the format. Unfortunately, that doesn't play well with any form of packaging, because bundler will immediately cause the application to abort when it attempts to write to the read-only Gemfile.lock in the store. We work around this by normalizing the Gemfile.lock with the version of Bundler that we'll use at runtime before we copy it into the store. This feels fragile, but it's the best we can do without changes upstream, or resorting to more delicate hacks. With all of the challenges in using Bundler, one might wonder why we can't just cut Bundler out of the picture and use RubyGems. After all, Nix provides most of the isolation that Bundler is used for anyway. The problem, however, is that almost every Rails application calls `Bundler::require` at startup (by way of the default project templates). Because bundler will then, by default, `require` each gem listed in the Gemfile, Rails applications are almost always written such that none of the source files explicitly require their dependencies. That leaves us with two options: support and use Bundler, or maintain massive patches for every Rails application that we package. Closes #8612
2015-11-15 02:17:29 +00:00
dontBuild = false;
2015-01-22 01:33:19 +00:00
buildInputs = [ xapian pkgconfig zlib ];
postPatch = ''
cp ${./xapian-Rakefile} Rakefile
'';
preInstall = ''
export XAPIAN_CONFIG=${xapian}/bin/xapian-config
'';
};
2016-04-17 21:36:40 +01:00
2014-10-28 04:16:14 +00:00
}