Layout della directory per il progetto Ruby puro

Question

Sto iniziando a imparare Ruby.Sono anche uno sviluppatore C++ quotidiano.Per i progetti C++ di solito scelgo la seguente struttura di directory

/
 -/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.

Quale layout di directory per Ruby (non Rails, non Merb) suggeriresti per mantenerlo pulito, semplice e gestibile?

Answer 1

Bundler include l'infrastruttura necessaria per generare una gemma:

$ 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

Quindi, in lib/, crei i moduli secondo necessità:

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

Leggi la pagina di manuale di gemma in bundle per i dettagli su --coc, --exe E --mit opzioni.

Answer 2

A partire dal 2011, è comune da usare gioielliere invece di newgem poiché quest'ultimo viene effettivamente abbandonato.

Answer 3

La struttura centrale di un progetto Ruby standard è fondamentalmente:

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

IL share/ è raro e talvolta viene chiamato data/ Invece.È per file non Ruby di uso generale.La maggior parte dei progetti non ne ha bisogno, ma anche quando lo fa molte volte, tutto viene semplicemente mantenuto lib/, anche se probabilmente non è la pratica migliore.

IL test/ potrebbe essere chiamata la directory spec/ se viene utilizzato BDD anziché TDD, anche se potresti anche vedere features/ se viene utilizzato il cetriolo, o demo/ se viene utilizzata la QED.

In questi giorni foo.gemspec può semplicemente essere .gemspec --specialmente se non viene mantenuto manualmente.

Se il tuo progetto ha eseguibili da riga di comando, aggiungi:

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

Inoltre, la maggior parte dei progetti Ruby hanno:

  Gemfile
  Rakefile

IL Gemfile serve per usare Bundler e il Rakefile è per lo strumento di creazione Rake.Ma ci sono altre opzioni se desideri utilizzare strumenti diversi.

Alcuni altri file non così rari:

  VERSION
  MANIFEST

IL VERSION il file contiene solo il numero di versione corrente.E il MANIFEST (O Manifest.txt) contiene un elenco di file da includere nei file del pacchetto del progetto (ad es.pacchetto di gemme).

Cos'altro potresti vedere, ma l'utilizzo è sporadico:

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

Dove config/ contiene vari file di configurazione; doc/ contiene la documentazione generata, ad es.RDoc, o talvolta documentazione mantenuta manualmente; script/ contiene script di shell da utilizzare nel progetto; log/ contiene i log di progetto generati, ad es.rapporti sulla copertura dei test; pkg/ contiene i file del pacchetto generati, ad es. foo-1.0.0.gem; task/ potrebbe contenere vari file di attività come foo.rake O foo.watchr; vendor/ contiene copie degli altri progetti, ad es.sottomoduli git;e infine web/ contiene i file del sito web del progetto.

Quindi alcuni file specifici dello strumento che sono anche relativamente comuni:

  .document
  .gitignore
  .yardopts
  .travis.yml

Sono abbastanza auto-esplicativi.

Infine, aggiungerò che personalmente aggiungo a .index file e a var/ directory per creare quel file (cerca "Rubyworks Indexer" per ulteriori informazioni) e spesso hanno un file work directory, qualcosa del tipo:

  work/
    NOTES.md
    consider/
    reference/
    sandbox/

Solo una specie di deposito di rottami per scopi di sviluppo.

Answer 4

@Dentharg:il tuo "includi uno per includere tutte le sottoparti" è un modello comune.Come ogni cosa, ha i suoi vantaggi (è facile ottenere ciò che desideri) e i suoi svantaggi (le numerose inclusioni possono inquinare gli spazi dei nomi e non hai alcun controllo su di essi).Il tuo modello assomiglia a questo:

- 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'
        ...

Potrei raccomandare questo per consentire un po' più di controllo:

- 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

Perché non utilizzare lo stesso layout?Normalmente non avrai bisogno di build perché non c'è un passaggio di compilazione, ma il resto mi sembra OK.

Non sono sicuro di cosa intendi per modulo, ma se è solo una singola classe non sarebbe necessaria una cartella separata e se c'è più di un file normalmente scrivi un file module-1.rb (a livello di nome come module-1 cartella) che non fa altro che richiedere tutto in module-1/.

Oh, e suggerirei di usarlo Rastrello per i compiti di gestione (invece di make).

Answer 6

Mi atterrei a qualcosa di simile a quello che conosci:non ha senso essere un estraneo nella directory del tuo progetto.:-)

Le cose tipiche che ho sempre sono lib|src, bin, test.

(Non mi piacciono questi generatori di mostri:la prima cosa che voglio fare con un nuovo progetto è scrivere del codice, non scrivere un README, documenti, ecc.!)

Answer 7

Quindi sono andato con newgem.Ho rimosso tutto il materiale RubyForge/gem non necessario (zappa, configurazione, ecc.), ho creato il repository git, ho importato il progetto in NetBeans.Tutto è durato 20 minuti e tutto è verde.Questo mi ha dato anche un compito di base per i file delle specifiche.

Grazie a tutti.