Layout de diretório para projeto Ruby puro

Question

Estou começando a aprender Ruby.Também sou um desenvolvedor diário de C++.Para projetos C++, geralmente uso a seguinte estrutura de diretório

/
 -/bin <- built binaries
 -/build <- build time temporary object (eg. .obj, cmake intermediates)
 -/doc <- manuals and/or Doxygen docs
 -/src
 --/module-1
 --/module-2
 -- non module specific sources, like main.cpp
 - IDE project files (.sln), etc.

Qual layout de diretório para Ruby (não-Rails, não-Merb) você sugeriria para mantê-lo limpo, simples e de fácil manutenção?

Answer 1

O Bundler inclui a infraestrutura necessária para gerar uma joia:

$ bundle gem --coc --mit --test=minitest --exe spider
Creating gem 'spider'...
MIT License enabled in config
Code of conduct enabled in config
      create  spider/Gemfile
      create  spider/lib/spider.rb
      create  spider/lib/spider/version.rb
      create  spider/spider.gemspec
      create  spider/Rakefile
      create  spider/README.md
      create  spider/bin/console
      create  spider/bin/setup
      create  spider/.gitignore
      create  spider/.travis.yml
      create  spider/test/test_helper.rb
      create  spider/test/spider_test.rb
      create  spider/LICENSE.txt
      create  spider/CODE_OF_CONDUCT.md
      create  spider/exe/spider
Initializing git repo in /Users/francois/Projects/spider
Gem 'spider' was successfully created. For more information on making a RubyGem visit https://bundler.io/guides/creating_gem.html

Então, em lib/, você cria módulos conforme necessário:

lib/
  spider/
    base.rb
  crawler/
    base.rb
  spider.rb
    require "spider/base"
    require "crawler/base"

Leia a página do manual para pacote de gema para detalhes sobre --coc, --exe e --mit opções.

Answer 2

A partir de 2011, é comum usar joalheiro em vez de newgem, pois este último é efetivamente abandonado.

Answer 3

A estrutura central de um projeto Ruby padrão é basicamente:

  lib/
    foo.rb
    foo/
  share/
    foo/
  test/
    helper.rb
    test_foo.rb
  HISTORY.md (or CHANGELOG.md)
  LICENSE.txt
  README.md
  foo.gemspec

O share/ é raro e às vezes é chamado data/ em vez de.É para arquivos não Ruby de uso geral.A maioria dos projetos não precisa disso, mas mesmo quando isso acontece muitas vezes, tudo é mantido lib/, embora essa provavelmente não seja a melhor prática.

O test/ diretório pode ser chamado spec/ se o BDD estiver sendo usado em vez do TDD, embora você também possa ver features/ se pepino for usado, ou demo/ se QED for usado.

Nos dias de hoje foo.gemspec pode apenas ser .gemspec --especialmente se não for mantido manualmente.

Se o seu projeto tiver executáveis ​​de linha de comando, adicione:

  bin/
    foo
  man/
    foo.1
    foo.1.md or foo.1.ronn

Além disso, a maioria dos projetos Ruby possui:

  Gemfile
  Rakefile

O Gemfile é para usar o Bundler, e o Rakefile é para a ferramenta de construção Rake.Mas existem outras opções se você quiser usar ferramentas diferentes.

Alguns outros arquivos não tão incomuns:

  VERSION
  MANIFEST

O VERSION arquivo contém apenas o número da versão atual.E a MANIFEST (ou Manifest.txt) contém uma lista de arquivos a serem incluídos no(s) arquivo(s) de pacote do projeto (por exemplo,pacote de gemas).

O que mais você pode ver, mas o uso é esporádico:

  config/
  doc/ (or docs/)
  script/
  log/
  pkg/
  task/ (or tasks/)
  vendor/
  web/ (or site/)

Onde config/ contém vários arquivos de configuração; doc/ contém documentação gerada, por ex.RDoc, ou às vezes documentação mantida manualmente; script/ contém scripts de shell para uso pelo projeto; log/ contém logs de projeto gerados, por ex.relatórios de cobertura de testes; pkg/ contém arquivos de pacote gerados, por ex. foo-1.0.0.gem; task/ pode conter vários arquivos de tarefas, como foo.rake ou foo.watchr; vendor/ contém cópias de outros projetos, por ex.submódulos git;e finalmente web/ contém os arquivos do site do projeto.

Depois, alguns arquivos específicos de ferramentas que também são relativamente comuns:

  .document
  .gitignore
  .yardopts
  .travis.yml

Eles são bastante autoexplicativos.

Por último, acrescentarei que adiciono pessoalmente uma .index arquivo e um var/ diretório para construir esse arquivo (pesquise "Rubyworks Indexer" para saber mais sobre isso) e geralmente tem um work diretório, algo como:

  work/
    NOTES.md
    consider/
    reference/
    sandbox/

Apenas uma espécie de ferro-velho para fins de desenvolvimento.

Answer 4

@Denharg:seu "incluir um para incluir todas as subpartes" é um padrão comum.Como qualquer coisa, ele tem suas vantagens (fácil de conseguir o que deseja) e suas desvantagens (as muitas inclusões podem poluir os namespaces e você não tem controle sobre eles).Seu padrão é assim:

- src/
    some_ruby_file.rb:
      require 'spider'
      Spider.do_something

+ doc/

- lib/
  - spider/
      spider.rb:
        $: << File.expand_path(File.dirname(__FILE__))
        module Spider
          # anything that needs to be done before including submodules
        end

        require 'spider/some_helper'
        require 'spider/some/other_helper'
        ...

Eu poderia recomendar isso para permitir um pouco mais de controle:

- src/
    some_ruby_file.rb:
      require 'spider'
      Spider.include_all
      Spider.do_something

+ doc/

- lib
  - spider/
      spider.rb:
        $: << File.expand_path(File.dirname(__FILE__))
        module Spider
          def self.include_all
            require 'spider/some_helper'
            require 'spider/some/other_helper'
            ...
          end
        end

Answer 5

Por que não usar apenas o mesmo layout?Normalmente você não precisará de compilação porque não há etapa de compilação, mas o resto parece bom para mim.

Não tenho certeza do que você quer dizer com módulo, mas se for apenas uma única classe, uma pasta separada não seria necessária e se houver mais de um arquivo, você normalmente escreve um arquivo module-1.rb (no nível do nome como o pasta module-1) que nada mais faz do que exigir tudo em module-1/.

Ah, e eu sugeriria usar Ancinho para as tarefas de gerenciamento (em vez de make).

Answer 6

Eu me limitaria a algo semelhante ao que você está familiarizado:não faz sentido ser um estranho no diretório do seu próprio projeto.:-)

Coisas típicas que sempre tenho são lib|src, bin, test.

(Eu não gosto desses geradores de monstros:a primeira coisa que quero fazer com um novo projeto é escrever algum código, não escrever um README, documentos, etc.!)

Answer 7

Então eu fui com newgem.Eu removi todas as coisas desnecessárias do RubyForge/gem (enxada, configuração, etc.), criei o repositório git, importei o projeto para o NetBeans.Tudo demorou 20 minutos e está tudo verde.Isso até me deu uma tarefa básica de rake para arquivos de especificações.

Obrigado a todos.