| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Because the gemdir was referenced on the derivation, it would cause the
whole gemdir to get added to the store, which would in turn force the
derivation to be rebuilt whenever unrelated folder files would change.
|
| |\
| |
| | |
_3llo: init at 0.3.0
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `gemset` field can be an attribute set as well in `buildRubyGem`,
however attribute sets can't be coerced to strings for the environment
set.
The impact should be relatively small as the environment variables are
only used by the `runCommand` script for `bunlderApp` which doesn't
refer to `gemset` at all.
|
| |/ |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Like `bundlerEnv`, the `gemdir` parameter to `bundlerApp` can be omitted
if all 3 of `gemfile`, `lockfile`, and `gemset` are provided.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| | |
|
| | |
|
| | |
|
| |
|