Commit Graph

21 Commits

Author SHA1 Message Date
Michael Weiss
b364139f2b
maintainers: remove pesterhazy
Their last commit was caf43ad5af from 2015.
Thank you for your contributions.
2021-05-13 13:00:47 +02:00
Michael Weiss
621a242a1a
jekyll: Remove myself as maintainer
I don't use it much anymore.
2021-05-13 12:54:36 +02:00
Michael Weiss
ec285b873f
jekyll: 4.0.0 -> 4.0.1 2020-05-10 15:18:31 +02:00
Michael Reilly
84cf00f980
treewide: Per RFC45, remove all unquoted URLs 2020-04-10 17:54:53 +01:00
volth
08f68313a4 treewide: remove redundant rec 2019-08-28 11:07:32 +00:00
Michael Weiss
d24aefd52f
jekyll: Improve the "jekyll new" experience
See https://github.com/NixOS/nixpkgs/issues/58126 for more details.

This will instruct the user how to manually finish the setup instead of
failing with error messages (unfortunately it is quite a bit hacky
though...).

Extra note:
We cannot use "bundle config --local" due to BUNDLE_GEMFILE (would
attempt to create .bundle/config in the Nix store) and manually creating
.bundle/config doesn't work either as these configuration variables are
still overwritten by the environment variables, even though this
shouldn't be the case [0].

[0]: https://bundler.io/v2.0/man/bundle-config.1.html
2019-06-28 16:12:15 +02:00
Michael Weiss
86a914adb4
jekyll: Switch from bundlerEnv to bundlerApp (#59327) 2019-04-11 23:05:46 +02:00
Michael Weiss
bd0ff570a2 jekyll: 3.7.2 -> 3.7.3 2018-02-28 15:10:58 +01:00
Michael Weiss
521ffc2398 jekyll: Update the dependencies without breaking the evaluation
Unfortunately my first attempt in f14b6ea broke the evaluation and was
therefore reverted in 4419a31. I couldn't reproduce the error locally
but as @grahamc noted I shouldn't have imported from a derivation.

Thanks @joachifm and @grahamc for spotting the evaluation error and
reverting f14b6ea.
2018-02-19 22:36:52 +01:00
Graham Christensen
4419a311f7
Revert "jekyll: Update the dependencies"
This reverts commit f14b6ea81f.

This commit added IFD to Nixpkgs, where
Nixpkgs should be IFD-free. (Import
from derivation.)
2018-02-19 13:55:48 -05:00
Michael Weiss
f14b6ea81f jekyll: Update the dependencies
The dependencies could be more minimal but this way it should hopefully
work for most use-cases.
2018-02-19 19:02:41 +01:00
Michael Weiss
d2919c996d jekyll: 3.4.1 -> 3.7.2 2018-02-19 17:43:26 +01:00
Samuel Dionne-Riel
7b97c8c0c8 treewide: homepage+src updates (found by repology, #33263) 2018-01-05 20:42:46 +01:00
Dmitry Kalinkin
171130e09a
jekyll: 3.0.1 -> 3.4.1 2017-03-03 20:08:53 -05:00
Jörg Thalheim
50a4b39b1e
jekyll: use gemdir 2017-01-18 00:52:53 +01:00
Vladimír Čunát
2d0893088f Merge branch 'master' into staging 2016-01-15 13:43:57 +01:00
Jakob Gillich
073a5e9e41 jekyll: 2.5.3 -> 3.0.1 2016-01-09 05:26:01 +01:00
Charles Strahan
b6c06e216b 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-12-29 09:30:21 -05:00
Tobias Geerinckx-Rice
158e1cfdd0 Don't use "with licenses;" for single licences
And don't use square brackets on such lines.
2015-05-28 19:20:29 +02:00
Paulus Esterhazy
89a58c9e05 Add Jekyll maintainer 2015-05-16 20:11:41 +02:00
Paulus Esterhazy
dd545e0fa4 Add Jekyll 2015-05-16 19:45:46 +02:00