bundlerApp: take buildInputs (#45435)
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`.
2018-10-29 21:39:51 +00:00
|
|
|
{ lib, stdenv, callPackage, runCommand, makeWrapper, ruby }@defs:
|
2017-05-31 17:44:46 +01:00
|
|
|
|
2017-06-26 01:40:22 +01:00
|
|
|
# Use for simple installation of Ruby tools shipped in a Gem.
|
|
|
|
# Start with a Gemfile that includes `gem <toolgem>`
|
|
|
|
# > nix-shell -p bundler bundix
|
|
|
|
# (shell)> bundle lock
|
|
|
|
# (shell)> bundix
|
|
|
|
# Then use rubyTool in the default.nix:
|
|
|
|
|
2017-06-28 06:33:18 +01:00
|
|
|
# rubyTool { pname = "gemifiedTool"; gemdir = ./.; exes = ["gemified-tool"]; }
|
2017-06-26 01:40:22 +01:00
|
|
|
# The 'exes' parameter ensures that a copy of e.g. rake doesn't polute the system.
|
2017-05-31 17:44:46 +01:00
|
|
|
{
|
2017-06-28 06:33:18 +01:00
|
|
|
# use the name of the name in question; its version will be picked up from the gemset
|
|
|
|
pname
|
2019-04-10 21:25:55 +01:00
|
|
|
# Gemdir is the location of the Gemfile{,.lock} and gemset.nix; usually ./.
|
|
|
|
# This is required unless gemfile, lockfile, and gemset are all provided
|
|
|
|
, gemdir ? null
|
2017-06-09 17:04:33 +01:00
|
|
|
# Exes is the list of executables provided by the gems in the Gemfile
|
2017-05-31 17:44:46 +01:00
|
|
|
, exes ? []
|
2017-06-11 00:58:32 +01:00
|
|
|
# Scripts are ruby programs depend on gems in the Gemfile (e.g. scripts/rails)
|
2017-05-31 17:44:46 +01:00
|
|
|
, scripts ? []
|
2017-06-11 01:38:49 +01:00
|
|
|
, ruby ? defs.ruby
|
2017-06-09 17:04:33 +01:00
|
|
|
, gemfile ? null
|
|
|
|
, lockfile ? null
|
|
|
|
, gemset ? null
|
2017-06-11 00:58:32 +01:00
|
|
|
, preferLocalBuild ? false
|
|
|
|
, allowSubstitutes ? false
|
2018-10-29 00:48:05 +00:00
|
|
|
, installManpages ? true
|
2017-06-11 01:11:37 +01:00
|
|
|
, meta ? {}
|
bundlerApp: take buildInputs (#45435)
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`.
2018-10-29 21:39:51 +00:00
|
|
|
, buildInputs ? []
|
2017-06-11 01:38:49 +01:00
|
|
|
, postBuild ? ""
|
2018-04-09 11:42:50 +01:00
|
|
|
, gemConfig ? null
|
2018-11-28 11:21:37 +00:00
|
|
|
, passthru ? {}
|
2017-05-31 17:44:46 +01:00
|
|
|
}@args:
|
|
|
|
|
|
|
|
let
|
2017-06-09 17:04:33 +01:00
|
|
|
basicEnv = (callPackage ../bundled-common {}) args;
|
2017-05-31 17:44:46 +01:00
|
|
|
|
2019-06-10 22:13:04 +01:00
|
|
|
cmdArgs = removeAttrs args [ "pname" "postBuild" "gemConfig" "passthru" ] // {
|
bundlerApp: take buildInputs (#45435)
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`.
2018-10-29 21:39:51 +00:00
|
|
|
inherit preferLocalBuild allowSubstitutes; # pass the defaults
|
|
|
|
|
|
|
|
buildInputs = buildInputs ++ lib.optional (scripts != []) makeWrapper;
|
2019-06-10 22:13:04 +01:00
|
|
|
|
|
|
|
passthru = basicEnv.passthru // {
|
|
|
|
inherit basicEnv;
|
|
|
|
inherit (basicEnv) env;
|
|
|
|
} // passthru;
|
bundlerApp: take buildInputs (#45435)
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`.
2018-10-29 21:39:51 +00:00
|
|
|
};
|
2017-05-31 17:44:46 +01:00
|
|
|
in
|
bundlerApp: take buildInputs (#45435)
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`.
2018-10-29 21:39:51 +00:00
|
|
|
runCommand basicEnv.name cmdArgs ''
|
2018-10-29 00:48:05 +00:00
|
|
|
mkdir -p $out/bin
|
|
|
|
${(lib.concatMapStrings (x: "ln -s '${basicEnv}/bin/${x}' $out/bin/${x};\n") exes)}
|
|
|
|
${(lib.concatMapStrings (s: "makeWrapper $out/bin/$(basename ${s}) $srcdir/${s} " +
|
bundlerApp: take buildInputs (#45435)
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`.
2018-10-29 21:39:51 +00:00
|
|
|
"--set BUNDLE_GEMFILE ${basicEnv.confFiles}/Gemfile "+
|
|
|
|
"--set BUNDLE_PATH ${basicEnv}/${ruby.gemPath} "+
|
|
|
|
"--set BUNDLE_FROZEN 1 "+
|
|
|
|
"--set GEM_HOME ${basicEnv}/${ruby.gemPath} "+
|
|
|
|
"--set GEM_PATH ${basicEnv}/${ruby.gemPath} "+
|
|
|
|
"--run \"cd $srcdir\";\n") scripts)}
|
2018-10-29 00:48:05 +00:00
|
|
|
|
|
|
|
${lib.optionalString installManpages ''
|
|
|
|
for section in {1..9}; do
|
|
|
|
mandir="$out/share/man/man$section"
|
|
|
|
find -L ${basicEnv}/${ruby.gemPath}/gems/${basicEnv.name} \( -wholename "*/man/*.$section" -o -wholename "*/man/man$section/*.$section" \) -print -execdir mkdir -p $mandir \; -execdir cp '{}' $mandir \;
|
|
|
|
done
|
|
|
|
''}
|
2017-05-31 17:44:46 +01:00
|
|
|
''
|