Verzeichnis Layout für reines Ruby-Projekt

Question

Ich fange an, Ruby zu lernen. Ich bin auch ein täglicher C++ Entwickler. Für C++ Projekte in der Regel mit folgenden Verzeichnis-Struktur

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

Was dir das Layout für Ruby (nicht-Rails, nicht-Merb) würden Sie vorschlagen, sie sauber zu halten, einfach und wartbar ich gehen?

Answer 1

Sie konnten die newgem RubyGem installieren und lassen Sie es das Layout für Sie generieren.

$ gem install newgem 
$ newgem spider 
     create 
     create config 
     create doc 
     create lib 
     create script 
     create tasks 
     create lib/spider 
     create History.txt 
     create License.txt 
     create Rakefile 
     create README.txt 
     create PostInstall.txt 
     create setup.rb 
     create lib/spider.rb 
     create lib/spider/version.rb 
     create config/hoe.rb 
     create config/requirements.rb 
     create tasks/deployment.rake 
     create tasks/environment.rake 
     create tasks/website.rake 
    dependency install_test_unit 
     create test 
     create test/test_helper.rb 
     create test/test_spider.rb 
    dependency install_website 
     create website/javascripts 
     create website/stylesheets 
     exists script 
     exists tasks 
     create website/index.txt 
     create website/index.html 
     create script/txt2html 
     force tasks/website.rake 
    dependency plain_theme 
     exists  website/javascripts 
     exists  website/stylesheets 
     create  website/template.html.erb 
     create  website/stylesheets/screen.css 
     create  website/javascripts/rounded_corners_lite.inc.js 
    dependency install_rubigen_scripts 
     exists script 
     create script/generate 
     create script/destroy 
     create script/console 
     create Manifest.txt 
     readme readme 
Important 
========= 

* Open config/hoe.rb 
* Update missing details (gem description, dependent gems, etc.) 

Dann in lib/erstellen Sie Module je nach Bedarf:

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

Answer 2

Warum nicht nur das gleiche Layout verwenden? Normalerweise brauchst du kein Build, weil es keinen Kompilierungsschritt gibt, aber der Rest scheint mir OK zu sein.

Ich bin mir nicht sicher, was Sie mit einem Modul meinen, aber wenn es nur eine einzelne Klasse ist, wäre ein separater Ordner nicht notwendig und wenn es mehr als eine Datei gibt, schreiben Sie normalerweise eine Modul-1.rb-Datei Name level als Modul-1-Ordner), die nichts weiter als alles in Modul-1/erfordert.

Oh, und ich würde vorschlagen, Rake für die Verwaltungsaufgaben zu verwenden (statt zu machen).

Answer 3

@Dentharg: Ihr "Einschließen, um alle Unterteile einzuschließen" ist ein allgemeines Muster. Wie alles hat es seine Vorteile (leicht zu bekommen, was Sie wollen) und seine Nachteile (die vielen enthalten können Namespaces verschmutzen und Sie haben keine Kontrolle über sie). Ihr Muster sieht wie folgt aus:

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

Ich könnte dies empfehlen, ein wenig mehr Kontrolle zu ermöglichen:

- 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 4

ich etwas kleben würde ähnlich dem, was Sie sind vertraut mit: Es gibt keinen Sinn, ein Fremder in Ihrem eigenen Projektverzeichnis zu sein . :-)

Typische Dinge, die ich immer habe, sind lib | src, bin, test.

(Ich mag nicht diese Monster Generatoren: das erste, was ich mit einem neuen Projekt tun mag, ist einigen Code bekommt nach unten, nicht schreibt eine Readme, Dokumente, etc.!)

Answer 5

Also ging ich mit newgem. Ich habe alle unnötigen RubyForge/Gem Sachen (Hacke, Setup, etc.) entfernt, erstellt Git Repo, importiertes Projekt in NetBeans. Alles dauerte 20 Minuten und alles ist grün. Das gab mir sogar eine grundlegende Rake-Aufgabe für spec-Dateien.

Danke euch allen.

Answer 6

Ab 2011 ist es üblich, jeweler statt newgem zu verwenden, da letzteres effektiv aufgegeben wird.

Answer 7

Die Kernstruktur eines Standardprojekt Ruby ist im Grunde:

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

Die share/ ist selten und ist manchmal data/ statt genannt. Es ist für allgemeine nicht-Ruby-Dateien.Die meisten Projekte brauchen es nicht, aber selbst wenn sie es oft tun, wird alles nur in lib/ gehalten, obwohl das wahrscheinlich keine Best Practice ist.

Das test/ Verzeichnis könnte spec/ aufgerufen werden, wenn BDD statt TDD verwendet wird, obwohl Sie auch features/ sehen könnte, wenn Gurke verwendet wird, oder wenn demo/ QED verwendet wird.

In diesen Tagen foo.gemspec kann einfach .gemspec - besonders wenn es nicht manuell gepflegt wird.

Wenn Ihr Projekt Befehlszeile ausführbaren Dateien hat, dann fügen:

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

Zudem sind die meisten Ruby-Projekt haben:

Gemfile 
    Rakefile 

Die Gemfile für die Verwendung von Bündler ist, und die Rakefile ist für Rake Werkzeug bauen. Aber es gibt andere Möglichkeiten, wenn Sie verschiedene Werkzeuge verwenden möchten.

Ein paar andere nicht so ungewöhnlich Dateien:

VERSION 
    MANIFEST 

Die VERSION Datei enthält nur die aktuelle Versionsnummer. Und die MANIFEST (oder Manifest.txt) enthält eine Liste von Dateien, die in den Paketdateien des Projekts enthalten sein sollen (z. B. Gem-Paket).

Was Sie vielleicht anders sehen, aber Nutzung ist sporadisch:

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

Wo config/ verschiedene Konfigurationsdateien enthält; doc/ enthält entweder erzeugte Dokumentation, z. RDoc oder manchmal manuell gepflegte Dokumentation; script/ enthält Shell-Skripte zur Verwendung durch das Projekt; log/ enthält erzeugte Projektprotokolle, z.B. Testberichte; pkg/ enthält erzeugte Paketdateien, z.B. foo-1.0.0.gem; task/ könnte verschiedene Task-Dateien wie foo.rake oder foo.watchr halten; vendor/ enthält Kopien der anderen Projekte, z.B. git Submodule; und schließlich enthält web/ die Website-Dateien des Projekts.

Dann werden einige Werkzeug, um bestimmte Dateien, die auch relativ häufig sind:

.document 
    .gitignore 
    .yardopts 
    .travis.yml 

Sie sind ziemlich selbsterklärend.

Schließlich will ich hinzufügen, dass ich persönlich eine .index Datei hinzufügen und eine var/ Verzeichnis die Datei (Suche nach „Rubyworks Indexer“ für mehr darüber) zu bauen und haben oft ein work Verzeichnis, so etwas wie:

work/ 
    NOTES.md 
    consider/ 
    reference/ 
    sandbox/ 

Nur eine Art Schrottplatz für Entwicklungszwecke.