Disposition du répertoire pour un projet Ruby pur

Question

Je commence à apprendre le rubis.Je suis également développeur C++ au quotidien.Pour les projets C++, j'utilise généralement la structure de répertoire suivante

/
 -/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 disposition de répertoire pour Ruby (non-Rails, non-Merb) suggéreriez-vous pour le garder propre, simple et maintenable ?

Answer 1

Bundler comprend l'infrastructure nécessaire pour générer une gemme :

$ 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

Ensuite, dans lib/, vous créez les modules selon vos besoins :

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

Lisez la page de manuel pour paquet de pierres précieuses pour plus de détails sur le --coc, --exe et --mit choix.

Answer 2

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

Answer 3

La structure de base d'un projet Ruby standard 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/ plutôt.Il s'agit de fichiers non Ruby à usage général.La plupart des projets n'en ont pas besoin, mais même lorsqu'ils en ont besoin plusieurs fois, tout est simplement conservé lib/, bien que ce ne soit probablement pas la meilleure pratique.

Le test/ le répertoire peut être appelé spec/ si BDD est utilisé à la place de TDD, bien que vous puissiez également voir features/ si du concombre est utilisé, ou demo/ si QED est utilisé.

Ces jours foo.gemspec peut juste être .gemspec --surtout s'il n'est pas entretenu manuellement.

Si votre projet comporte des exécutables en ligne de commande, ajoutez :

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

De plus, la plupart des projets Ruby ont :

  Gemfile
  Rakefile

Le Gemfile est destiné à l'utilisation de Bundler, et le Rakefile est pour l'outil de construction Rake.Mais il existe d'autres options si vous souhaitez utiliser d'autres outils.

Quelques autres fichiers pas si rares :

  VERSION
  MANIFEST

Le VERSION le fichier contient simplement le numéro de version actuel.Et le MANIFEST (ou Manifest.txt) contient une liste de fichiers à inclure dans le(s) fichier(s) de package du projet (par ex.paquet de pierres précieuses).

Que pourriez-vous voir d'autre, 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 soit de la documentation générée, par ex.RDoc, ou parfois documentation maintenue manuellement ; script/ contient des scripts shell à utiliser par le projet ; log/ contient les journaux de projet générés, par ex.rapports de couverture des tests ; 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.

Puis quelques fichiers spécifiques à l'outil qui sont également relativement courants :

  .document
  .gitignore
  .yardopts
  .travis.yml

Ils sont assez explicites.

Enfin, j'ajouterai que j'ajoute personnellement un .index fichier et un var/ répertoire pour créer ce fichier (recherchez "Rubyworks Indexer" pour en savoir plus) et disposez souvent d'un work répertoire, quelque chose comme :

  work/
    NOTES.md
    consider/
    reference/
    sandbox/

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

Answer 4

@Dentharg:votre "inclure un pour inclure toutes les sous-parties" est un modèle courant.Comme toute chose, il a ses avantages (facile d'obtenir ce que vous voulez) et ses inconvénients (les nombreuses inclusions 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 ceci 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 5

Pourquoi ne pas utiliser la même mise en page ?Normalement, vous n'aurez pas besoin de build 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 module, mais s'il ne s'agit que d'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 (au niveau du nom comme dossier module-1) qui ne fait rien de plus que de nécessiter tout ce qui se trouve dans le module-1/.

Oh, et je suggérerais d'utiliser Râteau pour les tâches de gestion (au lieu de make).

Answer 6

Je m'en tiendrai à quelque chose de similaire à ce que vous connaissez :cela ne sert à rien 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 pas ces générateurs de monstres :la première chose que je veux faire avec un nouveau projet est de rédiger du code, pas d'écrire un README, des documents, etc. !)

Answer 7

Alors je suis allé avec newgem.J'ai supprimé tous les éléments RubyForge/gem inutiles (houe, configuration, etc.), créé le dépôt git et importé le projet dans NetBeans.Tout a pris 20 minutes et tout est au vert.Cela m'a même donné une tâche de base pour les fichiers de spécifications.

Merci à tous.