search

SciRuby / daru-io

daru-io is a plugin gem to the existing daru gem, which aims to add support to Importing DataFrames from / Exporting DataFrames to multiple formats.
http://www.rubydoc.info/github/athityakumar/daru-io/master/
MIT License
25 stars 9 forks source link

Update the dependent daru version #68

Closed mrkn closed 6 years ago

athityakumar commented 7 years ago

@mrkn - The order of the index has been changed with this update. Can you please change the tests accordingly?

mrkn commented 7 years ago

@athityakumar Ok, I'll do it.

arbox commented 7 years ago

Why ist daru a development dependency of daru-io?

athityakumar commented 7 years ago

@arbox - Sorry for the late reply.

mrkn commented 7 years ago

I'm working on fixing the failing tests, and it will be finished in the next week.

arbox commented 7 years ago

Hm, thank you for the response @athityakumar. IMHO a clear separation of development and runtime packages gives us a solution like the binary, development binary and source packages for Debian. What I mean is that a Gemspec should not manage development dependencies at all. Do it via Bundler.

But actually I miss the point of the problem here. I'd propose to make daru-io a soft dependency of Daru which means that users may want to decide themselves if they need additional IO capabilities in Daru.

Last week I worked a lot with Daru and JSON data, so I found it inconsistent to have such kind of strong dependencies between Daru and Daru-io on the one hand and many soft dependencies for particular Importers and Exporters like jsonpath on the other. My proposal would be:

mrkn commented 6 years ago

I hate rubocop... 😡

athityakumar commented 6 years ago

@mrkn - The changes look good to me. Let @zverok also have a look and approve before merging. 😄

@arbox - Hmm, we saw the rspec family as an example for the daru family. Thus, daru-io and daru-view are intended to be dependencies within daru core gem. IMHO, splitting daru-io into multiple gems for each format does seem overkill. But anyways, let's wait to hear from @zverok .

zverok commented 6 years ago

:microscope:

zverok commented 6 years ago

But actually I miss the point of the problem here. I'd propose to make daru-io a soft dependency of Daru which means that users may want to decide themselves if they need additional IO capabilities in Daru.

@arbox The idea is to make it hard dependency and remove any own IO capabilities from Daru, making it smaller and easier to maintain. I firmly believe at current state of things there is no point in splitting daru-io further (that's why all of its dependencies are soft). The user story is:

  1. I install daru, and get daru-io as a part of it, so I can use basic things like CSV load/dump at once.
  2. I may try to use advanced IO features like Excel or ActiveRecord, and two things will happen:
    • if my projects already depends on AR (which is pretty likely) or spreadsheet (which is less likely but possible, if I need Excel exports, already tried to do it by hands, but now want more flexibility), everything "just works";
    • otherwise, friendly error saying what to install, is raised.
  3. When daru-io is installed, anybody can use its API to quickly develop own importers/exporters, and even have them in separate gems.

I don't see how splitting daru-io in 1000 gems will bring any clarity (especially considering it is still young, and internal API may change, and changing 10-20 microgems on this event is less than desirable).

athityakumar commented 6 years ago

@arbox - I hope @zverok's answer clarifies your query. If you'd like to discuss more related to the dependencies, please feel free to open an issue. 😄

Thanks for sending the PR, @mrkn. Seeing that @zverok has also approved this PR, I'm merging this in. 👍