Open ronaldtse opened 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.
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:
metanorma-cli
should not include all flavors.metanorma
gem is where the flavors are included, nor it should include the CLI. Clearly the CLI should be implemented in metanorma-cli
.metanorma
to be the parser/reader library.metanorma-all-flavors
or metanorma-flavor-bundle
that includes the flavors. Or something else to contain the flavors.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.
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.
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.
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 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?
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.
From @skalee
I'm open. Let's discuss for a better alternative.