What are the requirements of the Ruby contrib layer?

[ghost]

When I open a ruby-file, the line below the modeline tells me [rbenv] could not locate .ruby-version or rbenv-version

When I press , i and answer yes to open a REPL, I get No matching directory found.

When I press , t b to run tests (with a test buffer open) I get a message No test among visible buffers or run earlier.

I have run gem install pry --verbose.

I have also started installing rbenv (will see if I am able to get it to work in the end).

Is there anything obvious I am missing since nothing in this layer seems to work for me? If so please tell me, and I'll add it to the README.md.

[ghost]

While the Spacemacs core works well, I think we should aim to make the following true for the contrib layers as well:

Spacemacs is a user-friendly and well-documented Emacs kit that integrates the best Emacs packages out there

As far as I can see, the contrib-layer README.md is inadequate for making the Ruby layer work. To get it to work it requires you to read the actual packages.el codefile, then look up the github pages of the individual packages included and start reading their docs/installs/howtos, which isn't user-friendly.

[syl20bnr]

You are right the ruby layer needs work. We should add a message like the one in the haskell layer:

This layer is still not fully adapted for Spacemacs, it needs you, Haskell experts, to improve it and make it consistent with the Spacemacs experience.

Spacemacs has 2 months of contribution history and it is still in beta, expect this kind of rough edges to happen.

@bru Do you see what is missing in @endrebak environment ?

[ghost]

(Didn't mean to sound so negative, btw.)

Perhaps it would be possible to have several layers for each language, one with very simple features with a very simple install, then a layer with all the bells and whistles, but a more difficult install?

Since I am unable to get the new Haskell layer to work properly, I'm just keeping the most basic HS layer that was included in the beginning. Perhaps this could be made an option for other users too by having a haskell-basic and haskell-advanced layer? The same could be made for ruby: have a simple layer with minimum config needed and no external dependencies and an advanced layer needing some tweaks/additional installs etc.

[bjarkevad]

@endrebak Exactly, what is the issue you're having with the Haskell layer? I'll gladly look into making it more flexible. The end goal is that it should be very easy to install and get set up correctly :)

[ghost]

Oops. It was stupid of me to drag that in as an example. I do not know why I can't get it to work and it is probably my fault; my point was that it is nice to have an alternative.

Not being able to find a layer that works for the languages you use is something that might turn people off from spacemacs (in the worst case).

[bjarkevad]

No no, it's totally fine bringing it up in this context imo. I think it might be a good idea having the layers figure out which external dependencies are available, and then enable features accordingly. What do you think of this approach versus having minimal layers?

On Sun, Dec 28, 2014, 22:09 Endre Bakken Stovner notifications@github.com wrote:

Oops. It was stupid of me to drag that in as an example. I do not know why I can't get it to work and it is probably my fault; my point was that it is nice to have an alternative.

Not being able to find a layer that works for the languages you use is something that might turn people off from spacemacs (in the worst case).

— Reply to this email directly or view it on GitHub https://github.com/syl20bnr/spacemacs/issues/350#issuecomment-68219550.

[syl20bnr]

I understand your frustration.

It is possible, depending on the layer, to add switches to enable advanced features but it should be done carefully otherwise we will end up with harder to understand layers (when there are too much configuration options for instance).

I'm not in favor to have several layers for the same language because they will introduce dependencies between the layers and this is the last thing I want in spacemacs (there will be some kind of hierarchicalish thing in spacemacs but it will be limited to one special use case which does not need hard dependencies, for instance for flycheck).

I'm in favor of monolithic layers approved and used by experts with well documented setup, features and key bindings. Those monolithic layers can be easily tweaked by the users by adding a layer on top of them and/or adding and excluding packages (some feature toggle can be achieved by just excluding a package).

The setup issues can be reduced to documentation, optional features and helper functions. If a feature requires non trivial setup of the user environment then we have to look if it can be made optional with an automatic toggle or a explicit flag variable to add to the dotfile. If is easier to write than to do :-)

The git layer has a toggle for github support for instance, it does not add to the complexity of the layer. In your case I see that with carefully chosen flags we could achieve a simple layer basis which can be augmented by turning on the flags. Once again, the motivation for such flags must be very strong or their implementation should be trivial and easy to use/document/understand.

[syl20bnr]

@bjarkevad I prefer the approach you described with automatic amd implicit toggles, if it makes sense.

For instance, not having a tool which is easy to install or setup is not a strong enough motivation to introduce flags or automatic toggles. The only concern for spacemacs is to provide a well documented README, the rest is the responsability of the dotfile management system of the user. We just cannot provide consistent cross-platform way to detect software installation and configuration, this is beyond the scope of spacemacs. Dealing with such concerns will weaken the project instead of making it better.

[bjarkevad]

@syl20bnr I think you're right. I'm going to work on the README for the Haskell layer next, it does need a lot of improvement. I'll be working on improving the README gradually as I put some more hours into working with the layer, since I'll probably stumble across some oddities and whatnot.

[syl20bnr]

Great ! One of the biggest value of spacemacs is in the documentation. This thread is a proof and thank you @endrebak to report these issues which are very important contributions to the project.

@bjarkevad I hope to have time during the holidays to code some haskell, hopefully I will be able to give you some feedbacks.

[bjarkevad]

That would be awesome @syl20bnr !

[ghost]

As a minimal move in a simpler direction, can we remove the rbenv package? It allows you to switch ruby versions (which is nice) - however it is mutually exclusive with rvm which is also very widely used (~6000 vs ~3000 github stars). None of the other ruby packages seems to hinge on having rbenv installed.

[bru]

Yep, RVM and rbenv are two mutually exclusive schools of thought on how to manage your local ruby environment. I think it should be possible to remove the dependency, however, most ruby developers will need either in order to get a working dev environment; hm, we could try with a switch to be set in your personal dotspacemacs...

On Mon, Dec 29, 2014 at 10:40 AM, Endre Bakken Stovner < notifications@github.com> wrote:

As a minimal move in a simpler direction, can we remove the rbenv package? It allows you to switch ruby versions (which is nice) - however it is mutually exclusive with rvm which is also very widely used (~6000 vs ~3000 github stars). None of the other ruby packages seems to hinge on having rbenv installed.

— Reply to this email directly or view it on GitHub https://github.com/syl20bnr/spacemacs/issues/350#issuecomment-68247282.

Riccardo CAMBIASSI http://twitter.com/bru

[ghost]

I have just commented out the package in my ruby layer; that will work for now. Someone cleverer than me should find out how to deal with the headache that is two widely used, but mutually exclusive ruby environment managers.

It might be that the largest user group are those that use neither rvm nor rbenv; just brew install-ing different ruby versions works well for me.

[syl20bnr]

@endrebak you don't have to comment the package, add it to the dotspacemacs-excluded-packages variable (https://github.com/syl20bnr/spacemacs/blob/master/core/templates/.spacemacs.template#L14-15).

@bru Exclusive packages can be possible in a layer if you dynamically play with the variable ruby-excluded-packages depending on the value of the variable. A suggested name for this variable could be ruby-version-manager and possible values rvm or rbenv.

[bru]

@syl20bnr gotcha, I'll have a play with this tonight, thx for the hint!

On Mon, Dec 29, 2014 at 12:07 PM, Sylvain Benner notifications@github.com wrote:

@endrebak https://github.com/endrebak you don't have to comment the package, add it to the dotspacemacs-excluded-packages variable ( https://github.com/syl20bnr/spacemacs/blob/master/core/templates/.spacemacs.template#L14-15 ).

@bru https://github.com/bru Exclusive packages can be possible in a layer if you dynamically play with the variable ruby-excluded-packages depending on the value of the variable. A suggested name for this variable could be ruby-version-manager and possible values rvm or rbenv.

— Reply to this email directly or view it on GitHub https://github.com/syl20bnr/spacemacs/issues/350#issuecomment-68252370.

Riccardo CAMBIASSI http://twitter.com/bru

[ghost]

"The setup issues can be reduced to documentation, optional features and helper functions."

Just out of curiosity, how much documentation do you think would be approriate? I am currently just linking to the homepage of the necessary packages (unless they are available with some simple install tool like brew/gem/cabal). Would you prefer it if there was loads more, arch-wiki style? (i.e. detailed instructions for installing packages for all oses/shells etc?)

[syl20bnr]

@endrebak If it is a one liner it can be included in the README directly. If it is several steps then a link to the documentation + github issues and gitter chat as fallbacks are enough to me.

[syl20bnr]

The Haskell parenthesis is closed with the commit of @endrebak.

Let's go back to the original topic which is Ruby.

[syl20bnr]

Since rvm and rbenv are mutually exclusive in the layer I close this. Feel free to reopen if needed.