Раскладка каталога для чистого Ruby-проекта
Я начинаю изучать рубин. Я также являюсь ежедневным разработчиком С++.
Для проектов С++ я обычно использую следующую структуру 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.
Какую директорию для Ruby (non-Rails, non-Merb) вы предложите сохранить в чистоте, простоте и обслуживании?
Ответы
Ответ 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 минут и все на зеленом.
Это даже дало мне основную задачу рейка для файлов спецификаций.
Спасибо всем.
