I don’t know a great “how to lay out” guide off-hand, but I’ll take a stab at helping with the confusion.

Rake is a Ruby equivalent of Make. Many Ruby gems will include rake tasks (Makefile targets) that can be used to drive pieces of an application. Most of the time your test framework of choice (rspec typically) will include “rake test” as a target for running the tests.

The tests usually live in a folder named “spec”, while application code lives in “lib” and your driver code lives in “bin” or just a top-level file… without some of the Rails initialization glue, you’ll have to do a little work to require files via relative paths or set up the $LOAD_PATH variable, etc.

Bundler is the package manager, and you’ll often see commands like “bundle exec rake”, this is similar in spirit to a virtualenv. Bundler will use the libraries defined in your Gemfile to run the given program (in this case, ‘rake’). The command “bundle” will read the Gemfile and resolve dependencies to concrete versions of libraries and write out a Gemfile.lock for you with all the versions explicitly defined.

For debugging, there are a number of tools out there, but I’m partial to ‘pry’. You add pry to your Gemfile, require it, and then can add a breakpoint by putting a call to “binding.pry” in your source code wherever. This will drop you into a REPL within the context of the program at that point.

pry is useful, but there are some other gems and settings files out there that can make it a little friendlier, pry-byebug comes to mind as having saner keyboard shortcuts iirc.

If you need help with overall file system layout, etc, the best place to look is going to be existing trivial gems on rubygems.org. Granted these will have a couple of minor differences from a “plain” application because they’re packaging as a library (*.gemspec file instead of Gemfile, and usually has a version.rb file somewhere).

Thanks for the awesome reply! This has been really useful, I was mostly confused about bundle/rake now I understand most of the things to through rake but bundle just provides the env, makes sense.

Also I created a project with bundle, which gave me some structure, and downloaded Rubymine which is helping a lot as well, even if it's a tiny project, also it suggests me new cool things Ruby can do which I had not idea about.

Bundler has a nice subcommands for setting up a new gem. Setting up a test framework depends on which one you pick. The big switch from rails is that you get to decide where everything goes. I suggest looking at some recently created gems by prolific rubyists to get a feel for the structure.

I agree with @tinco. If you're doing Ruby development that is not Rails, you probably want to create a gem with Bundler. I'd check out their documentation on the subject which has some good information: https://bundler.io/guides/creating_gem.html. I'd also checkout https://www.learnenough.com/ruby. I haven't walked through the course, but Michael Hartl has been providing Ruby related learning materials for a long time and is a fairly trusted name in the community. I'm sure it's solid.

If you want to make a cli application with ruby i'd suggest thor or dry-cli as a gem(package in other languages).

rake is ruby make... aka a build utility but it can and is used for a variety of things like testing and building and distribution.

minitest is built in and is generally enough. rspec is the other big one and a lot of people like it but it's fairly complicated and it is better to stick to the basic one early on.

as for debugging puts debugging is common(though a lot of things are caught at the testing phase since testing is big with ruby). if you are familiar with debuggers that is also an option with something like vscode or the command line but vscode is more usable(or the rubymine one that is a paid app).

`bundle gem foo` will create a subdirectory `foo` and setup a decent starting skeleton for a gem named 'foo'. I'd maybe suggest 'standard' over 'rubocop' as a linter to begin with.

  foo/
    - foo.gemspec: needs to fix the TODOs to start, and this is where runtime deps will go
    - Gemfile: where your development deps will go
    - Gemfile.lock: built by 'bundle install' do not touch
    - Rakefile: the build system (build gems, push gems, run tests, etc)
    - bin/ drop binary scripts here or delete if you're making a library (generally make them tiny stubs that require "foo" or "foo/application" and call run on the app or something)
    - lib/ this is where you put all your code.  already setup with lib/foo.rb and lib/foo/version.rb which are accessible via `require "foo"` and `require "foo/version"` mostly you'll want to put code under lib/foo/ and then have `lib/foo.rb` be a pile of require statements (ish).
    - spec/ this is where tests go.  bundler will set you up with rspec installed to begin with with a spec_helper.rb already setup (this is where you tweak rspec).  i would suggest using spec/unit/whatever_spec.rb to test lib/foo/whatever.rb and keeping those directory structures roughly in sync for your unit tests.

To get started:

  bundle install  # updates all the gems in the Gemfile (plus the referenced gemspec file) and installs rspec and updated rake and stuff
  bundle exec rake spec  # runs all the spec/ tests
  bundle exec rake # runs rake + rubocop/standard both
  bundle exec rake -T # shows all the rake tasks
  bundle exec rake release # will build and push the gem to rubygems publicly