Update the dependent daru version

[mrkn]

No description provided.

[athityakumar]

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

[mrkn]

@athityakumar Ok, I'll do it.

[arbox]

Why ist daru a development dependency of daru-io?

[athityakumar]

@arbox - Sorry for the late reply.

• Ideally, daru should be a runtime-dependency of daru-io.
• But, daru-io is also a core module to daru. Hence, we're setting daru-io as a runtime-dependency of daru.
• Setting both gems as runtime-dependencies of each other sets an infinite loop during installation of either gem.
• @zverok and I discussed here about how to proceed. We came up with the solution: let daru be development-dependency of daru-io, and daru-io be runtime-dependency of daru.

[mrkn]

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

[arbox]

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:

• split Daru-io in separate gems for every format like Daru-io-json and set for them a runtime dependency on Daru, not soft dependencies are allowed, so Daru-io-json will depend in the runtime on jsonpath
• convert Daru-io in a metagem depending on Daru and all format io gems
• make Daru-io and/or all format gems soft dependencies of Daru and inform the user on additional possibilities.
  Soft dependencies are rather inconvenient from the user perspective but otherwise there is no need for concern separation and Daru vs. Daru-io as separate projects.
  What do you think?

[mrkn]

I hate rubocop... 😡

[athityakumar]

@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]

🔬

[zverok]

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]

@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. 👍