search

louismullie / treat

Natural language processing framework for Ruby.
Other
1.37k stars 128 forks source link

Installer is doing too many things #4

Closed kshahkshah closed 12 years ago

kshahkshah commented 12 years ago

I like the automated installer but it appears to be duplicating the efforts of rubygems.

For instance in dependencies.rb there are listed 12 gems which could simply be listed as runtime dependencies in the treat.gemspec file.

Also, the external binary libraries doesn't inform you of what to install if you choose to install manually. That information is only available on the wiki.

This is more of meta issues, but I did find a small bug as well which I will fork and fix.

louismullie commented 12 years ago

Hey,

First, thanks a lot for your bug fix!

Concerning the dependencies, initially I did have them as rubygems dependencies. However, the reason I switched them to the installer is because none of them is essential to the functioning of all the library (since the whole library is based on pluggable wrappers, of which none are really essential to the core). Therefore, I believe it doesn't make sense to ask the user to install all of them by default - accordingly, the installer gives the user this additional freedom of choice. IMHO, this is only one more example to highlight that optional dependencies are crucially missing to rubygems. What do you think?

Also, what do you mean by "the external binary libraries doesn't inform you of what to install"? Didn't you get the message saying, e.g.:

Do you want to install ocropus to recognize text in image files (y/n)?

I am not sure if I understand well.

Thanks for your input, Louis

bobbytables commented 12 years ago

Instead of an installer theres modules that know how to check for the dependency? IE.

raise 'Please add "gem 'stanford-nlp' to your gemfile" unless defined?(StanfordNLP)

louismullie commented 12 years ago

Yes, that is another possibility that I thought of - e.g. defining a treat_require function and using that across the library. But I don't really see the advantage of that versus the installer ?

bobbytables commented 12 years ago

Installer is a bit of an uncommon case. Albeit, it's a great idea. Ruby developers tend to know that when you load a module / class, that class knows how to take care of it's dependencies. (autoload for example).

I think that if we were to create a great "Getting Started" guide that encapsulated setting StanfordNLP or Enju up with the installer, there could be huge advantages. But we also have to consider production environments, that just want to install the gem and dependencies separately because of a chef script.

louismullie commented 12 years ago

I'll close this issue unless somebody has a precise modification to propose?