make serve versus bundle exec jekyll serve
Closed this issue · 20 comments
For windows 10, make serve fails for me but bundle exec jekyll serve runs. (Thanks for your help, @zkamvar @Denubis @ldko and @maxim-belkin on getting this figured out). It sounds like the instruction section "For Everyone" needs to be updated to reflect this if it's a more general issue for all Windows computers.
Just a note to clarify and narrow down the issue:
- This was an issue with the makefile not finding python despite
which pythonproducing a working python 3 installation. bundle exec jekyll servewill only work for lessons that do not need to render RMarkdown.
... I think there are 3 different threads here, since jekyll is ruby based.
Looking at the makefile -- it checks for python presence regardless of its use, but doesn't check for ruby/docker. The only need we have for python are for the x-check.py files, which may not be why people are trying to run this locally. Also, as ruby/jekyll moves forward, bundle exec jekyll serve is much more robust.
@fmichonneau I think we need to think about the makefile versus "being able to run the thing locally" While it's trivial to change the makefile to bundle exec, ruby is quite fragile. Should we move to a pure dockerised makefile/environment? Or should we move to a package-manager approach?
I can only half follow this thread, but for @Denubis 's second comment:
@zkamvar is talking about how when you run make serve on my computer, it pings the error
"Makefile:32: *** "Your system does not appear to have any Python installed.". Stop." even though I do have python installed (which you can see through which python but not which python3). There's something with the way the Makefile is looking for python that is partially causing some errors (Makefile lines 25-34)
However, this may be completely off topic. Just clarifying why we're talking about python at all!
Yes, the makefile scans for python, then runs the command you asked it to run, which in this case is an instruction to ruby's package manager to run jekyll. My discussion is more that it feels like we're trying to do too many things in too many routes -- and if we really really need 3 different programming languages for our lesson template (I get why, since I'm partly at fault for contributing pythonic stuff) do we want to go to a pure docker based build strategy?
Sorry for being so jargony, @kelseygonzalez. Happy to explain stuff at length if you would like me to unpack any of it.
Just to get a sense of things, you're running the website to be able to preview your local edits before doing a checkout patch, right? Not as part of lesson development?
I agree that 3 languages is kind of excessive, which is probably by @zkamvar 's docker solution is a potential path forward and away from this confusion.
Correct, I'm not running it for lesson development but just for maintaining lessons. However, I maintain an R lesson and bundle exec jeckyll serve doesn't render the .rmd files whereas make serve supposedly does.
I don't 100% need to preview locally, but because this is built into the maintainer onboarding process and the lesson development process, so I think it's worth investing in getting the instructions right for Windows, since I'm not the only one struggling. There's a few other new maintainers working on Windows who I believe just gave up on getting it to work.
Ok, so a quick fix would be to scan for python later on in the process before python is about to be invoked. What shell are you using on windows?
Ok, reading the makefile. @kelseygonzalez can you test https://github.com/Denubis/lesson-example allows you to both make rmd lessons and serve them?
@fmichonneau I think we need to think about the makefile versus "being able to run the thing locally" While it's trivial to change the makefile to bundle exec, ruby is quite fragile. Should we move to a pure dockerised makefile/environment? Or should we move to a package-manager approach?
@Denubis To that note, we have created a dockerized container that bundles all of the requirements at https://github.com/carpentries/lesson-docker#readme We are also investigating ways to minimize these kinds of issues, which may include dropping our dependency on jekyll/bundler/ruby.
10:05 $ make serve
make: /bin/bash: Command not found
make: /bin/bash: Command not found
python_error is: "Your system does not appear to have any Python installed.". Python based make-commands may not work.
make: /bin/bash: Command not found
make: *** [Makefile:137: _episodes/05-rmarkdown-example.md] Error 127
@Denubis : just ran make serve on git bash, here's the output
10:05 $ make serve
make: /bin/bash: Command not found
make: /bin/bash: Command not found
python_error is: "Your system does not appear to have any Python installed.". Python based make-commands may not work.
make: /bin/bash: Command not found
make: *** [Makefile:137: _episodes/05-rmarkdown-example.md] Error 127
What do you get when you execute which bash ?
$ which bash
/usr/bin/bash
Could you please try changing export SHELL = /bin/bashline in the Makefile to export SHELL = /usr/bin/bash and see if it helps your issue?
Could you please try changing
export SHELL = /bin/bashline in the Makefile toexport SHELL = /usr/bin/bashand see if it helps your issue?
no change in the result
Ok, this seems to be like an opportunity for a chat. Can you book in a time that works for you (probably on the other side of the world) https://calendly.com/brian-ballsun-stanton -- I think this will be a great opportunity to debug. I note that the make error you recently got is distinct from the prior errors, since that looks like an error in compiling the rmd. make: *** [Makefile:137: _episodes/05-rmarkdown-example.md] Error 127 is what blocked running.
I think if we can debug on your system it might be a useful way of making these instructions more robust.
Issue resolved in carpentries/lesson-example#293 -- forcing variables to set shell instead of using the shell's path and invoking bash explicitly was the issue. We also need to consolidate installation, because the documentation has us do a fair amount of manual work that the makefile also has us do. Is it worth spending time to fix this?
by manual work, @Denubis is referring to the bundle update line that the lesson set up tells us to run, when the makefile is already running bundle update.
side note: when running bundle update, it gives the following warning. We may want to move away from ruby sass.
Ruby Sass has reached end-of-life and should no longer be used.
* If you use Sass as a command-line tool, we recommend using Dart Sass, the new
primary implementation: https://sass-lang.com/install
* If you use Sass as a plug-in for a Ruby web framework, we recommend using the
sassc gem: https://github.com/sass/sassc-ruby#readme
* For more details, please refer to the Sass blog:
https://sass-lang.com/blog/posts/7828841
I've transferred this issue to the styles repository. We'll review the PR that Brian has put in once it's in this repo.
Regarding the message from Ruby Sass, we rely on the gems that come as dependencies from GitHub Pages and so this is outside our control. However, this dependency issue should get fixed in the near future.
created conversation #480 from this. Short version: patching hard-coded bash locations out of a makefile is not an effective measure if we can't test if it works. Let's discuss what we want our testing framework to look like first?
I think the Makefile has been greatly improved since this discussion. Feel free to re-open or create a new issue if something like this happens again.