Раскладка каталога для чистого Ruby-проекта

Ответ 1

Вы можете установить newgem RubyGem и позволить ему генерировать макет для вас.

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

Затем в lib/вы создаете модули по мере необходимости:

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

Ответ 2

По состоянию на 2011 год обычно используется jeweler вместо newgem, поскольку последний фактически отменяется.

Ответ 3

Основная структура стандартного проекта Ruby в основном:

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

share/ встречается редко и иногда называется data/. Это для нерубинных файлов общего назначения. Большинство проектов им не нужны, но даже когда они делают много раз, все просто сохраняется в lib/, хотя это, вероятно, не самая лучшая практика.

Каталог test/ может быть вызван spec/, если вместо TDD используется BDD, хотя вы можете также видеть features/, если используется Cucumber, или demo/, если используется QED.

В наши дни foo.gemspec может быть только .gemspec - особенно если он не поддерживается вручную.

Если в вашем проекте есть исполняемые файлы командной строки, добавьте:

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

Кроме того, в большинстве проектов Ruby есть:

  Gemfile
  Rakefile

Gemfile предназначен для использования Bundler, а Rakefile - для инструмента построения Rake. Но есть и другие варианты, если вы хотите использовать разные инструменты.

Несколько других не очень редких файлов:

  VERSION
  MANIFEST

Файл VERSION содержит только текущий номер версии. И MANIFEST (или Manifest.txt) содержит список файлов, которые должны быть включены в файл (-ы) пакета проекта (например, gem-пакет).

Что еще вы можете увидеть, но использование является спорадическим:

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

Где config/ содержит различные файлы конфигурации; doc/ содержит либо сгенерированную документацию, например. RDoc, а иногда и вручную поддерживаемую документацию; script/ содержит сценарии оболочки для использования проектом; log/ содержит сгенерированные журналы проектов, например. отчеты по охвату тестированием; pkg/ содержит сгенерированные файлы пакетов, например. foo-1.0.0.gem; task/ может содержать различные файлы задач, такие как foo.rake или foo.watchr; vendor/ содержит копии других проектов, например. git подмодули; и, наконец, web/ содержит файлы веб-сайта проекта.

Затем некоторые файлы конкретных инструментов, которые также являются относительно распространенными:

  .document
  .gitignore
  .yardopts
  .travis.yml

Они довольно понятны.

Наконец, я добавлю, что лично добавляю файл .index и каталог var/ для создания этого файла (поиск по "Rubyworks Indexer" для получения дополнительной информации об этом) и часто имеет каталог work, что-то вроде

  work/
    NOTES.md
    consider/
    reference/
    sandbox/

Просто свалка для целей развития.

Ответ 4

@Dentharg: ваш "включить один для включения всех подчастей" является общим шаблоном. Как и все, он имеет свои преимущества (легко получить то, что вы хотите) и его недостатки (многие из них могут загрязнять пространства имен, и у вас нет контроля над ними). Ваш шаблон выглядит следующим образом:

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

Я бы рекомендовал это, чтобы позволить немного больше контроля:

- 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

Ответ 5

Почему бы не использовать один и тот же макет? Обычно вам не нужно строить, потому что нет этапа компиляции, но остальное мне кажется хорошо.

Я не уверен, что вы подразумеваете под модулем, но если это просто один класс, отдельная папка не понадобится, и если там более одного файла, вы обычно пишете файл module-1.rb(по имени уровень как папка module-1), которая делает не что иное, как требование всего в модуле-1/.

О, и я бы предложил использовать Rake для задач управления (вместо make).

Ответ 6

Я бы придерживался чего-то похожего на то, с чем вы знакомы: нет никакого смысла быть незнакомцем в вашем собственном каталоге проекта.: -)

Типичные вещи, которые у меня всегда есть: lib | src, bin, test.

(Мне не нравятся эти генераторы-монстры: первое, что я хочу сделать с новым проектом, - получить код вниз, а не писать README, docs и т.д.!)

Ответ 7

Итак, я пошел с newgem. Я удалил все ненужные вещи RubyForge/gem (мотыги, настройки и т.д.), Создал git repo, импортировал проект в NetBeans. Все заняли 20 минут и все на зеленом. Это даже дало мне основную задачу рейка для файлов спецификаций.

Спасибо всем.