Gem paths craziness on cygwin
Locked
 
|
I'm not sure if the problems I have with getting gem paths to work properly are just generic ruby/gem problems but since a lot of gem installs are needed in asciidoctor, I thought I would ask here (after spending many hours scouring StackOverflow and similar places for help)...
I had a lot of trouble getting asciidoctor-pdf to run, because it installed in /usr/local/gems, but when I try to run it, it couldn't be found. gem env showed that /usr/local was indeed in the Gem path, but if I did $ruby -r rubygems -e "p Gem.path" it wasn't. I fixed this by doing 'export GEM_PATH=/usr/local:$GEM_PATH'. However, I would prefer to know how gem figures out its paths, and why ruby has different paths. After this, I tried to get the compass stylesheet stuff going. Similar problem, except compass, sass etc all installed in my ~/.gem area (why?!?!) and then could not be found when invoking it. I moved it manually to /usr/local/gems, and copied the /bin scripts to /usr/local/bin, but still no luck. Using bundler appears to have messed with the paths. If I get a new bash shell, and do 'gem env', I get 4 paths: - /usr/local - /home/Thomas/.gem/ruby - /usr/share/gems - /usr/local/share/gems If I then do 'compass compile' I get this: /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- compass (LoadError) from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require' from /usr/local/bin/compass:20:in `block in <main>' from /usr/local/bin/compass:8:in `fallback_load_path' from /usr/local/bin/compass:19:in `<main>' Compare this to ruby's idea of the paths: $ ruby -r rubygems -e "p Gem.path" ["/home/Thomas/.gem/ruby", "/usr/share/gems", "/usr/local/share/gems"] ... no /usr/local! But if I do 'export GEM_PATH=/usr/local:$GEM_PATH', I end up with only /usr/local as the GEM path according to gem env.... As you might guess, this situation is pretty irritating for someone who is a non-ruby/gem user! I have been unable to locate anywhere online clear information about how these paths are set, and why 'gem' and 'ruby' have different ideas of these paths. I have seen a lot of other posts relating to similar problems however. Is the ruby/gems world really so arcane? any help appreciated... |
Re: Gem paths craziness on cygwin
Administrator
|
I explained the situation in detail in the following comment: The simple solution is to update your PATH environment variable so that it can see the launch script (e.g., asciidoctor or asciidoctor-pdf). Once the launch script is found, Ruby will handle the rest. If you're on Cygwin, by default `gem install` will install the gem into your home directory. The launch scripts (aka binstubs) will end up in the bin directory. Thus, you need to add $HOME/bin to your PATH environment variable. $ export PATH="$HOME/bin:$PATH" (Cygwin really should setup the PATH this way by default). If you're in an environment where `gem install` installs the gem to system location, such as /usr/local/bin, then you need to add this path to your PATH environment variable instead. $ export PATH="/usr/local/bin:$PATH" You shouldn't need to mess with GEM_PATH unless you want the gems to install to a different location than the default. Different distributions (including Cygwin and OSX) like to setup Ruby differently. This is not really Ruby's fault. These distributions are just being difficult IMO... which is why I like and recommend RVM (https://rvm.io). RVM manages the Ruby environment so that it just works. It rarely, if ever, lets me down. Cheers, -Dan On Tue, Jun 23, 2015 at 11:11 AM, wolandscat [via Asciidoctor :: Discussion] <[hidden email]> wrote: I'm not sure if the problems I have with getting gem paths to work properly are just generic ruby/gem problems but since a lot of gem installs are needed in asciidoctor, I thought I would ask here (after spending many hours scouring StackOverflow and similar places for help)... Dan Allen | http://google.com/profiles/dan.j.allen |
Re: Gem paths craziness on cygwin
|
Administrator
|
In reply to this post by wolandscat
I discovered that you can force the gems to install into the system on Cygwin by doing the following. $ export GEM_HOME=/usr/share/gems In this case, the binstubs will end up in /usr/share/gems/bin, which you need to add to your PATH: $ export PATH="/usr/share/gems/bin:$PATH" The advantage of installing your own gems into your home directory, though, is that they are kept separate from the system gems (installed with the package manager). Again, RVM also helps make this distinction. -Dan On Tue, Jun 23, 2015 at 3:42 PM, Dan Allen <[hidden email]> wrote:
Dan Allen | http://google.com/profiles/dan.j.allen |
|
|
In reply to this post by mojavelinux
Your explanation on the asciidoctor Github is very clear. It's very odd for me seeing things install into ~/; but I realise I am used to thinking in terms of servers, not single user machines (even though my cygwin laptop is of course just that, I still see no point in having anything installed in ~/).
I now have rvm on the machine correctly installed as far as I can tell. Since I already have a 'system' ruby, I told it to use that (rvm use system). I also set GEM_HOME to /usr/local in ~/.bash_profile. Then I opened a new bash, just to make sure everything is source'd properly; removed old compass / sass install from /usr/local and reran the 'bundle install' command in a git checkout of http://github.com/asciidoctor/asciidoctor-stylesheet-factory, as per this page. I'm not sure that rvm is doing anything interesting here as such, but the new gems went into /usr/local/gems, and 'compass compile' now seems to work. So the environment seems healthier. It might be worth adding a few helpful tips somewhere in the install documentation to say either to set GEM_HOME or else to include ~/bin in the PATH, since most newcomers won't know to do the first, and if they don't do it, and also don't have ~/bin in the path (also very common), nothing's going to work. Anyway - thanks for the help, now to try and get PDFs working! |
Re: Gem paths craziness on cygwin
|
Administrator
|
On Tue, Jun 23, 2015 at 6:23 PM, wolandscat [via Asciidoctor :: Discussion] <[hidden email]> wrote: I now have rvm on the machine correctly installed as far as I can tell. Since I already have a 'system' ruby, I told it to use that (rvm use system). I also set GEM_HOME to /usr/local in ~/.bash_profile. Oops. I forgot to mention that "system" ruby means that RVM is effectively disabled. You have to install at least one Ruby for RVM to be truly functional. I agree that more instructions are necessary in the documentation regarding gem installation (esp since the documentation available for RubyGems is pretty confusing). A lot of this content belongs in the planned "contributing" guide since anything that is still in alpha is not really ready for general usage. The README can then focus on general usage...a happier path so to speak towards installation. Cheers, |
Re: Gem paths craziness on cygwin
|
Administrator
|
In reply to this post by wolandscat
On Tue, Jun 23, 2015 at 6:23 PM, wolandscat [via Asciidoctor :: Discussion] <[hidden email]> wrote: So the environment seems healthier. It might be worth adding a few helpful tips somewhere in the install documentation to say either to set GEM_HOME or else to include ~/bin in the PATH, since most newcomers won't know to do the first, and if they don't do it, and also don't have ~/bin in the path (also very common), nothing's going to work. I did put something similar together for OSX, but I think we need something that covers more environments. (See http://asciidoctor.org/docs/install-asciidoctor-macosx/). |
|
|
In reply to this post by mojavelinux
Aha... I have to say that even after carefully reading the rvm examples and basics pages, and running most of the commands, nowhere is it obvious that if you use the system ruby, rvm is not really doing anything. So that's another trap for first-timers.
There really needs to be a neon-light page somewhere on ruby, gems, rvm and the site of every tool written in ruby that says: WAIT, STOP don't even think about touching any of these things unless you have built your ruby ecosystem following these steps: 0. determine intended gem install area (somehow) & set up shell env accordingly 1. install rvm ... 2. rvm managed install of ruby 3. set up bundler ... 4. general method for install / uninstall of X Like any normal cygwin user, I use the cygwin installer for everything (and make no mistake, it works just as well as apt-get or anything on any Linux server). But it's probably the wrong thing to use with ruby/gems, which I am starting to see is really its own ecosystem. Although Asciidoctor is just one of probably thousands of Ruby tools out there, maybe it could pioneer such a page - it would really help. Ruby may be common amongst some, but in our community, which has thousands of developers all over the world, only our Japanese group uses it that I am aware of (so far). However, many more of us will use Asciidoctor and related tools. So you can see the challenge... |
Re: Gem paths craziness on cygwin
|
Administrator
|
On Wed, Jun 24, 2015 at 4:41 AM, wolandscat [via Asciidoctor :: Discussion] <[hidden email]> wrote: nowhere is it obvious that if you use the system ruby, rvm is not really doing anything. So that's another trap for first-timers. I agree. This is my only real gripe about RVM. Would you be willing to file an issue against RVM? There really needs to be a neon-light page somewhere on ruby, gems, rvm and the site of every tool written in ruby that says: WAIT, STOP don't even think about touching any of these things unless you have built your ruby ecosystem following these steps: Although Asciidoctor is just one of probably thousands of Ruby tools out there, maybe it could pioneer such a page - it would really help. I've filed an issue to add such a guide to asciidoctor.org. We can't solve the problem for the whole Ruby ecosystem, but we can solve the problem for our users. Like any normal cygwin user, I use the cygwin installer for everything (and make no mistake, it works just as well as apt-get or anything on any Linux server). I agree it works great. I still maintain my position that it is not setting up the Ruby environment right for gem installation, though. But, we can document our way around it :) it's probably the wrong thing to use with ruby/gems, which I am starting to see is really its own ecosystem. Not necessarily. First, it would help if we got asciidoctor added as a package in Cygwin. I'll look into that. Then, you can avoid the whole gem installation. After all, that's why we have packages for Fedora and Debian. Second, I've always been of the opinion that system Ruby is for the system. If the system needs Ruby to operate, of course, it uses the system Ruby and its gems. If you need gems for your applications, then you install them in your home directory. This is the same thing we do with Java libraries. We don't use jar files installed in the system for our applications (we use the dependency manager in our build to go fetch them). System programs do use system-wide jars. That's why I like RVM. I have my Ruby. The system has its Ruby. They are separate. And I shouldn't even care that the system has Ruby. (Btw, I'm not sure if you know about it, but I encourage you to check out http://babun.github.io/. It's a preconfigured Cygwin environment complete with a package manager command by some folks we know). I want to finish off by saying that using Ruby isn't your only option to using Asciidoctor. We have AsciidoctorJ and Asciidoctor.js, neither of which require any Ruby environment on your machine. So we come at this problem from multiple angles. While we want to make the installation of Asciidoctor (Ruby) straightforward and easy, we also have other options. For casual users, the best way to use Asciidoctor is via the Chrome or Firefox extension because then you avoid messing with any commands at all. Cheers, |
|
|
Re: rvm - done, see this issue.
Babun looks interesting - I've always been a unix guy (used to work on Solaris and SunOS workstations and I manage a few servers in the background), so I've put cygwin on every Windows PC I've had for the last 15+ years. Old habits like that make one somewhat oblivious to nice new things like this. Re: which tools: I'm perfectly fine with the ruby/gem based tools, but I would just say that a big 'getting started safely' page is needed for devs and others (I'm no longer really a dev, apart from some compiler building in Eiffel language ;-) who are not ruby-ites. I'd personally rather see one set of tools, bullet-proof installation info, and more functionality rather than replication. There's no one perfect language any more, and Java has its own problems - use Eclipse? (free but like bringing an aircraft carrier to a fishing trip) Use IntelliJ? (Ok if you're already a java dev). And so on. The main challenge in any language technology isn't the language, it's learning the libraries and frameworks. Our goal in this is to replace the publishing setup we had with FrameMaker, and have a single source tool chain generating HTML (maybe more than one kind) and PDF, based on documentation fragments and images extracted from UML tools - instlalled in a continuous build environment with push events coming from the Github source repos. So far (once we got past the gem gremlins) it's looking very possible - assuming we can tame the PDF side. There's a fair way to go to replicate Frame's output quality (especially with ePub back-end for HTML), but the Asciidoctor toolchain looks like it will go close, and the HTML output stage coupled with the stylesheet-factory (even I managed to create a decent custom stylesheet) is very good indeed (last thing to get right there is more powerful internal Xrefs). I think it's crucial to retain as separate the various levels of formatting directives, so that a core 'master.adoc' really can be published nicely in HTML, PDF, DocBook etc, and I see that that is indeed the mentality of the development approach, so that's good to see. BTW, you are welcome to use our asciidoc development repo as a reference test location for long technical documents with HTML and PDF output, and a lot of file including, plus custom stylesheets. Still fairly rough, but it could be useful for testing. |
«
Return to Asciidoctor :: Discussion
|
1 view|%1 views
| Free forum by Nabble | Edit this page |