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

ruby code-formatting

9483 просмотра

7 ответа

Я начинаю изучать рубин. Я также являюсь ежедневным разработчиком C ++. Для проектов на C ++ я обычно использую следующую структуру 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) вы предложите сохранить в чистоте, простоте и обслуживании?

Автор: Marcin Gil Источник Размещён: 17.05.2019 04:00

Ответы (7)


11 плюса

Решение

Bundler включает в себя необходимую инфраструктуру для создания драгоценного камня:

$ 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

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

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

Прочитайте страницу руководства расслоения самоцвета для получения сведений об --coc, --exeи --mitопциях.

Автор: François Beausoleil Размещён: 15.09.2008 01:41

20 плюса

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

Автор: troutwine Размещён: 15.08.2011 02:00

11 плюса

Основная структура стандартного проекта 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/если BDD используется вместо TDD, хотя вы можете также увидеть , features/если используются огурец, или demo/если используется QED.

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

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

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

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

  Gemfile
  Rakefile

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

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

  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/

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

Автор: trans Размещён: 24.12.2012 09:23

2 плюса

@ 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
Автор: James A. Rosen Размещён: 11.09.2008 12:46

1 плюс

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

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

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

Автор: ujh Размещён: 11.09.2008 12:07

0 плюса

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

Обычно у меня всегда есть lib | src, bin, test.

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

Автор: 0124816 Размещён: 16.09.2008 12:03

0 плюса

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

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

Автор: Marcin Gil Размещён: 17.09.2008 12:44
Вопросы из категории :
32x32