Disposition du répertoire pour le projet Ruby pur

Question

Je commence à apprendre le rubis. Je suis aussi un développeur C++ au jour le jour. Pour les projets C je vais habituellement avec la structure suivante dir

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

Quelle mise en page dir pour Ruby (non-Rails, non Merb) proposeriez-vous pour le garder propre, simple et maintenable? Pourquoi ne pas utiliser exactement la même mise en page?

Answer 1

Vous pouvez installer le rubygem de newgem et laissez générer la mise en page pour vous.

$ 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.) 

Puis, dans lib /, vous créez des modules selon les besoins:

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

Answer 2

Normalement, vous n'aurez pas besoin de construire car il n'y a pas d'étape de compilation, mais le reste me semble OK. Je ne suis pas sûr de ce que vous entendez par un module, mais si c'est juste une seule classe un dossier séparé ne serait pas nécessaire et s'il y a plus d'un fichier, vous écrivez normalement un fichier module-1.rb (à la niveau de nom comme le dossier module-1) qui ne fait rien de plus que de tout exiger dans le module-1 /.

Oh, et je suggère d'utiliser Rake pour les tâches de gestion (au lieu de faire).

Answer 3

@Dentharg: votre "inclure un pour inclure toutes les sous-parties" est un modèle courant. Comme tout, il a ses avantages (facile d'obtenir les choses que vous voulez) et ses inconvénients (les nombreux inclus peuvent polluer les espaces de noms et vous n'avez aucun contrôle sur eux). Votre modèle ressemble à ceci:

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

je pourrais recommander ce pour permettre un peu plus de contrôle:

- 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

Je tiendrais à quelque chose de semblable à ce que vous connaissez bien: il n'y a pas de point d'être un étranger dans votre propre répertoire de projet . :-)

Les choses typiques que j'ai toujours sont lib | src, bin, test.

(Je n'aime ces générateurs de monstres: la première chose que je veux faire avec un nouveau projet est d'obtenir un code vers le bas, pas écrire un fichier README, docs, etc.!)

Answer 5

Je suis allé avec newgem. J'ai enlevé toutes les choses inutiles RubyForge/gem (houe, configuration, etc.), créé repo git, projet importé dans NetBeans. Tout a pris 20 minutes et tout est vert. Cela m'a même donné une tâche de rake de base pour les fichiers spec.

Merci à tous.

Answer 6

Depuis 2011, il est courant d'utiliser jeweler au lieu de newgem car ce dernier est effectivement abandonné.

Answer 7

La structure de base d'un projet de norme Ruby est essentiellement:

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

Le share/ est rare et est parfois appelé data/ place. C'est pour les fichiers non-ruby d'usage général.La plupart des projets n'en ont pas besoin, mais même quand ils le font plusieurs fois tout est simplement conservé dans lib/, bien que ce ne soit probablement pas la meilleure pratique.

Le répertoire test/ pourrait être appelé spec/ si BDD est utilisé au lieu de TDD, mais vous pouvez également voir features/ si concombre est utilisé, ou si demo/ QED est utilisé.

Ces jours foo.gemspec peuvent simplement être .gemspec - spécialement si elle n'est pas gérée manuellement.

Si votre projet a executables la ligne de commande, puis ajouter:

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

De plus, son projet le plus Ruby ont:

Gemfile 
    Rakefile 

Le Gemfile est pour l'utilisation Bundler et le Rakefile est pour Rake construire un outil. Mais il existe d'autres options si vous souhaitez utiliser différents outils.

Quelques autres fichiers pas si rare:

VERSION 
    MANIFEST 

Le fichier VERSION ne contient que le numéro de version. Et le MANIFEST (ou Manifest.txt) contient une liste de fichiers à inclure dans le (s) fichier (s) de package du projet (par exemple, le paquet gem).

Ce que vous pourriez voir, mais l'utilisation est sporadique:

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

Où config/ contient divers fichiers de configuration; doc/ contient une documentation générée, par ex. RDoc, ou parfois de la documentation maintenue manuellement; script/ contient des scripts shell à utiliser par le projet; log/ contient des journaux de projet générés, par ex. rapports de couverture de test; pkg/ contient les fichiers de package générés, par ex. foo-1.0.0.gem; task/ pourrait contenir divers fichiers de tâches tels que foo.rake ou foo.watchr; vendor/ contient des copies des autres projets, par ex. sous-modules git; et enfin web/ contient les fichiers du site Web du projet.

Ensuite, certains fichiers spécifiques d'outils qui sont aussi relativement fréquents:

.document 
    .gitignore 
    .yardopts 
    .travis.yml 

Ils sont assez explicites.

Enfin, je vais ajouter que j'ajouter personnellement un fichier .index et un répertoire var/ pour construire ce fichier (recherche de « Rubyworks indexeur » pour plus à ce sujet) et ont souvent un répertoire work, quelque chose comme:

work/ 
    NOTES.md 
    consider/ 
    reference/ 
    sandbox/ 

Juste une sorte de ferraille à des fins de développement.