for local use, recommend Bundler and provide config #361
Conversation
|
review by @heathermiller and @fsalvi note that I have no idea how closely the components and versions in the Gemfile.lock match what is actually used in production. however, I don't think that actually matters as far as merging this, because:
|
SethTisue
force-pushed
the
add-gemfile
branch
from
8436887
to
f16bb40
Compare
so that people can test the site locally without having to install stuff systemwide on their local machines originally contributed by Simon as part of a larger PR, so I've retained him as author on the commit. the only significant thing I (Seth) did differently was specify Jekyll 2, not 3, in Gemfile.lock, since Jekyll 2 is what we're using in production
SethTisue
force-pushed
the
add-gemfile
branch
from
f16bb40
to
340e6ec
Compare
|
@heathermiller is this OK to merge...? |
|
Well, I just tried it using the production server configuration, and it's not ok: /resources/js/vendor is missing because of the exclude line in _config.yml |
|
@fsalvi thanks for taking the time to test this. what version of Jekyll are we running in production? it looks to me from jekyll/jekyll#1915 that it should work in current Jekyll to use an initial slash to anchor the excluded path to the root. but to be sure this will work, I need to know what version of Jekyll is expected. |
|
Not sure if this is running on chara, but: So, it's old. I've been told that Fabien plans on updating Ruby etc on that machine in the coming months, which should eventually enable us to upgrade to Jekyll 3. |
|
wow, that is old! OK, I'm going to close this for now while I think about whether to put together a Gemfile.lock with that version, or just wait for the upgrade, or what. I would be eager to help with the upgrade (within the limits of my not very extensive experience with this stuff). |
|
Well, before reinstalling the server (which I plan to do in April), we could upgrade to jekyll 1.5.1 if this is useful... |
|
It probably is useful! |
|
yes, moving to 1.5.1 would be a huge improvement |
|
to respond to Heather's questions on Gitter:
yes, this is a blocker for me. @soc obviously considers it important as well. scala-lang isn't the only Ruby app on my machine, and I'm not willing to make global visible changes to my Ruby setup in order to preview changes to one website. partly because I consider it undesirable; partly because I lack the knowledge and competence to troubleshoot any resulting conflicts; and partly because I think it's undesirable to impose this requirement on other contributors as well. that's why I consider it essential for us to provide a proper Gemfile and Gemfile.lock. we already do this right over in the docs.scala-lang repo; we ought to do it right in this repo, too. I'm not just griping — I want to fix it myself. I've been just moving slowly on it. @fsalvi can you tell me exactly what version of Jekyll chara is running? is it 0.11.2? so far I only know what version Heather has installed on her local machine. if I'm going to go through the process of producing a Gemfile/Gemfile.lock combo for an old version of Jekyll (perhaps this will actually be quite easy? I don't know yet, I'm learning this stuff as I go), I would prefer to know beforehand exactly what Jekyll version I'm targeting. |
|
P.S. perhaps this is all based on some misconception of mine. it's hard for me to be sure since I'm not expert on this stuff. over at #197, you said "I use Jekyll versions 1-3 across computers to build locally without issue". as far as I know, the only way that's possible is using Gemfile/Gemfile.lock, which we don't yet have in this repo? if there is some other method by which multiple Jekyll versions can coexist, I don't know what it is. |
|
Yes, it is: jekyll -v It has remained the same version since the development of the web site in July 2013. |
|
awesome! I'm perfectly happy to postpone the Gemfile stuff a little while and wait for that upgrade. |
|
The main reason I'd like to upgrade is that the current markdown parser is very broken. I've spent hours already trying to make stuff parse that previews just fine locally and on github. Almost 20% of my commits in this repo are to fix maruku issues: 57112df (HEAD -> 2016-update) last formatting tweak |
|
I switched to redcarpet recently, because that's the one used ("required") by the Scala spec, and have been pretty happy so far. As far as I know, maruku is considered to be obsolete by its authors, and Jekyll switched to another parser in 2.0 ... (kramdown?). Kramdown should work fine, too, I just picked redcarpet because of all the special options being used for the spec, and it working fine with content from both scala-lang, docs.scala-lang and the spec. |
|
@fsalvi the ball is your court. Redcarpet or kramdown or whatever one elects to use is another dependency that must be added to the build machine. |
|
Well, I just did a test using kramdown to build the website and it looks ok. It's even much fast, 10s for kramdown instead of 59s for maruku ! I will switch to it next week on the production server in the same time I upgrade jekyll. |
|
Awesome, thanks Fabien :) |
|
Thanks, @fsalvi! |
|
Ok, I just did the modifcations and built the website. It looks good, but let me know if you see anything wrong. Thanks. |
|
thanks so much @fsalvi. I haven't noticed any problems on the site in the last few days. |
so that people can test the site locally without having to install stuff systemwide on their local machines based on an earlier version originally contributed by Simon Ochsenreither as part of a larger PR the choice of Jekyll 1.5.1, for now, is based on Fabien's comments at scala#361
|
successor PR at #373 |
so that people can test the site locally without having to install stuff systemwide on their local machines based on an earlier version originally contributed by Simon Ochsenreither as part of a larger PR the choice of Jekyll 1.5.1, for now, is based on Fabien's comments at scala#361 particular version numbers for other gems are from Fabien's comment at scala#373 (comment)
so that people can test the site locally without having to
install stuff systemwide on their local machines
originally contributed by @soc as part of a larger PR (#359), so I've
retained him as author on the commit. the only significant thing I
(@SethTisue) did differently was specify Jekyll 2, not 3, in
Gemfile.lock, since Jekyll 2 is what we're using in production