[RFE] install/build dependency

[voxik]

Recent version of nokogiri introduces runtime dependency on mini_portile. However, this is actually not a runtime dependency, but install time dependency, which is needed just for build of nokogiri's binary extension.

Would it be possible to get rid of such (non)runtime dependency? It is of any use for Windows users, since they get nokogiri precompiled and it is of any use for Fedora users, since they install precompiled rubygem-nokogiri as well. I believe this apply also for other distributions.

Thanks for considering.

[luislavena]

Can you point to the commit that introduced that?

Mini portile should only be used as development dependency.

Sorry for top posting. Sent from mobile.
On Aug 27, 2013 9:54 AM, "Vít Ondruch" notifications@github.com wrote:

Recent version of nokogiri introduces runtime dependency on mini_portile.
However, this is actually not a runtime dependency, but install time
dependency, which is needed just for build of nokogiri's binary extension.

Would it be possible to get rid of such (non)runtime dependency? It is of
any use for Windows users, since they get nokogiri precompiled and it is of
any use for Fedora users, since they install precompiled rubygem-nokogiri
as well. I believe this apply also for other distributions.

Thanks for considering.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/624
.

[luislavena]

Found the change:

sparklemotion/nokogiri@3f30720

However, I think you should open this request at Nokogiri project and not
RubyGem.

Will get in touch with @tenderlove and @flavorjones to workaround solutions
for this.

On Tue, Aug 27, 2013 at 9:54 AM, Vít Ondruch notifications@github.comwrote:

Recent version of nokogiri introduces runtime dependency on mini_portile.
However, this is actually not a runtime dependency, but install time
dependency, which is needed just for build of nokogiri's binary extension.

Would it be possible to get rid of such (non)runtime dependency? It is of
any use for Windows users, since they get nokogiri precompiled and it is of
any use for Fedora users, since they install precompiled rubygem-nokogiri
as well. I believe this apply also for other distributions.

Thanks for considering.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/624
.

Luis Lavena

AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[voxik]

sparklemotion/nokogiri@4ded299
sparklemotion/nokogiri@3f30720
sparklemotion/nokogiri@3a25297

[voxik]

Yes, the upstream ticket is referenced above in the stream

[flavorjones]

It's there intentionally ... will pick up the thread in the nokogiri issue.

[drbrain]

It is possible to add a new dependency type to RubyGems, but only if there is a definite need. I will wait for the outcome of sparklemotion/nokogiri#956

[luislavena]

I found myself in the need of build time dependencies several times with
different projects.

[knu]

I think it would be a great addition to this to introduce an "installed-by-dependency" flag for installed gems that could help user clean up gems that are installed by build-time dependency. (with apt-get autoremove of the Debian package system in mind)

[drbrain]

I think a build dependency should be automatically uninstalled after its dependee is installed, but the cached .gem file should remain to reduce download time for future uses. This way the user doesn't have to worry about cleaning up such gems.

[luislavena]

I think a build dependency should be automatically uninstalled after its dependee is installed, but the cached .gem file should remain to reduce download time for future uses. This way the user doesn't have to worry about cleaning up such gems.

Where do I send my check? 😄

[drbrain]

I've moved this up to the "Future" milestone.

The rumor is that the Ruby 2.1 feature freeze will come at the end of September, so this feature needs to be in master before then. That leaves about one month to implement it.

Unfortunately for this new feature, I will be traveling to Moscow to give a talk at the end of September, so this reduces my time to work on RubyGems.

[voxik]

Actually, looking into this matter once more, I am not sure that simple build dependency solves this issue. In nokogiri's case, we don't need mini_portile on Fedora at all, since we are going to build against system libxml2.

In other words, we are going to use this [1] branch, while the mini_portile is needed just for the else part [2].

Any idea how to solve this use case?

[1] https://github.com/sparklemotion/nokogiri/blob/master/ext/nokogiri/extconf.rb#L153
[2] https://github.com/sparklemotion/nokogiri/blob/master/ext/nokogiri/extconf.rb#L194

[flavorjones]

Can you explain why this dependency is causing so much pain?
On Aug 29, 2013 5:53 AM, "Vít Ondruch" notifications@github.com wrote:

Actually, looking into this matter once more, I am not sure that simple
build dependency solves this issue. In nokogiri's case, we don't need
mini_portile on Fedora at all, since we are going to build against system
libxml2.

In other words, we are going to use this [1] branch, while the
mini_portile is needed just for the else part [2].

Any idea how to solve this use case?

[1]
https://github.com/sparklemotion/nokogiri/blob/master/ext/nokogiri/extconf.rb#L153
[2]
https://github.com/sparklemotion/nokogiri/blob/master/ext/nokogiri/extconf.rb#L194

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/624#issuecomment-23478363
.

[drbrain]

@flavorjones historically @voxik has submitted issues to RubyGems with regard to converting gems to RPMs. I suspect that he wants to package nokogiri as an RPM with only the dependencies needed to for runtime.

[voxik]

@drbrain @flavorjones Yes, that is exactly it. At this case, we don't need mini_portile even for build.