metanorma / metanorma-cli

CLI (Command Line Interface) for Metanorma
BSD 2-Clause "Simplified" License
5 stars 5 forks source link

Potentially move flavor dependencies to `metanorma` gem? #120

Open ronaldtse opened 5 years ago

ronaldtse commented 5 years ago

From @skalee

there's also something I don't like in mn-cli it has plenty of dependencies it's like mn-bundle at the moment and raw metanorma has no CLI interface at the moment at all but generally, I'd rather move CLI features to Metanorma gem

I'm open. Let's discuss for a better alternative.

skalee commented 5 years ago

My comments from discussion with @opoudjis

IMO there's no point in maintaining mn-cli as a separate gem. CLI is nothing but another interface for metanorma. Managing compatibility between mn and mn-cli only makes dependency management more difficult. IMO CLI should be merged into metanorma gem. I suppose the only reason that it is currently separated is that mn-cli introduces plenty of additional dependencies. But I think that either they should be made optional, or that some extra features should be extracted to another gems. Besides, having CLI in a separate gem with so many dependencies means that you either need to install everything, or have no CLI at all.

ronaldtse commented 5 years ago

The situation today is the metanorma gem provides a generic interface for Metanorma flavor gems, like metanorma-iso.

My intention of the metanorma gem was meant to be used to parse and write a Metanorma data structure. i.e.

a = Metanorma::Document.new
a.title = "ISO 1234"
a.to_xml => <XML document output>

b = Metanorma::Document.parse("./metanorma-document.xml")
b.title => "ISO 1234"

Here's what I think:

  1. I agree that metanorma-cli should not include all flavors.
  2. I do not agree that metanorma gem is where the flavors are included, nor it should include the CLI. Clearly the CLI should be implemented in metanorma-cli.
  3. I want metanorma to be the parser/reader library.
  4. Maybe we can have a separate metanorma-all-flavors or metanorma-flavor-bundle that includes the flavors. Or something else to contain the flavors.
skalee commented 5 years ago

In my opinion the key problems are as follows. It appears that @ronaldtse disagrees with it, at least partially. Also I'm disagreeing with myself as well, because some of my observations are contradictory. Anyway, here are my comments.

Metanorma-CLI has a huge amount of runtime dependencies

As of current master,

  spec.add_runtime_dependency "thor", "~> 0.20.3"
  spec.add_runtime_dependency "metanorma-iso", "~> 1.3.0"
  spec.add_runtime_dependency 'metanorma-ietf', "~> 1.0.1"
  spec.add_runtime_dependency 'metanorma-gb', "~> 1.3.0"
  spec.add_runtime_dependency 'metanorma-iec', "~> 0.0.5"
  spec.add_runtime_dependency 'metanorma-csd', "~> 1.3.0"
  spec.add_runtime_dependency 'metanorma-csand', "~> 1.3.0"
  #spec.add_runtime_dependency 'metanorma-rsd', "~> 1.1.0"
  spec.add_runtime_dependency 'metanorma-m3d', "~> 1.3.0"
  spec.add_runtime_dependency 'metanorma-acme', "~> 1.3.0"
  spec.add_runtime_dependency 'metanorma-standoc', "~> 1.3.0"
  #spec.add_runtime_dependency 'metanorma-mpfd', "~> 0.1.0"
  spec.add_runtime_dependency 'metanorma-unece', "~> 0.2.0"
  spec.add_runtime_dependency 'metanorma-ogc', "~> 0.2.0"
  spec.add_runtime_dependency 'metanorma-nist', "~> 0.2.0"
  spec.add_runtime_dependency 'metanorma-itu', "~> 0.2.0"
  spec.add_runtime_dependency 'isodoc', "~> 1.0.0"
  spec.add_runtime_dependency 'metanorma', "~> 0.3.9"
  #spec.add_runtime_dependency 'nokogiri', ">= 1"
  spec.add_runtime_dependency "git", "~> 1.5"

Multiple flavours and Git integration. That means that you cannot have any CLI interface without installing all of that.

Managing compatibility between Metanorma and Metanorma-CLI will be difficult

CLI is nothing but another interface for Metanorma. Every new feature in Metanorma is likely to trigger CLI update, and every update to CLI will typically be a consequence of changes in Metanorma. Both gems need to be maintained together. Moreover, they'll always be tightly coupled. IMO these are strong arguments for merging them into one thing.

In Ruby world, extracting CLI gems is not a common practice

Rails' CLI is provided by Railties gem, which has other responsibilities as well. RSpec's CLI is provided by RSpec-Core gem, which also provides the core framework for structuring tests. Searching for "CLI" on RubyGems does not return any of popular gems, unless they're standalone CLI interfaces for remote services (like heroku).

This is not without reason. Extracting CLI features only increases maintenance burden (see managing compatibility difficulties) without actually giving much in return. It doesn't even make code base noticeably smaller.

Separate CLI packages are typical for JavaScript world for a reason unknown to me.

Metanorma-CLI actually does things

Metanorma-CLI is not a thin wrapper for a Metanorma's public API (well, non-existence of such API is another thing). Instead, it is performing file operations itself. Perhaps it's just a misleading gem name? Or separation of concerns went wrong?

ronaldtse commented 2 years ago

The biggest issue here is this:

Metanorma-CLI actually does things

Metanorma-CLI is not a thin wrapper for a Metanorma's public API (well, non-existence of such API is another thing). Instead, it is performing file operations itself. Perhaps it's just a misleading gem name? Or separation of concerns went wrong?

There should be a defined Metanorma library API.

Metanorma is supposed to be a library first, then the CLI attached to it second.