[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" [email protected] 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 [email protected]:

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" [email protected] 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.

[flavorjones]

OK, got it.

Creating a new type of gem dependency seems like a heavyweight solution.
Wouldn't it be easier to maintain a downstream RPM branch of nokogiri, with
the mini_portile code removed from extconf.rb and the gemspec?

If necessary I am happy to allow setting an env var at gem-creation-time
that will omit mini-portile and use system libraries. Then you don't even
need to maintain a branch; just 'git clone' and 'rake gem.

WDYT?
On Aug 30, 2013 3:16 AM, "Vít Ondruch" [email protected] wrote:

@drbrain https://github.com/drbrain @flavorjoneshttps://github.com/flavorjonesYes, that is exactly it. At this case, we don't need mini_portile even for
build.

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

[drbrain]

Since we have multiple people requesting the feature, and I trust then, I don't think it is too heavyweight.

In the mean time, for backwards compatibility, other solutions may be necessary.

[copiousfreetime]

I believe this issue is effectively proposing a new dependency type for the rubygems. A build_dependency that would need to be resolved by the installer and is used during the installation of a primary gem. After the primary gem is installed, the build_dependency gem would be removed and its .gem file left in the local cache.

[flavorjones]

I'm pleased and surprised to see this issue getting attention again. Let me know how I can support.

[voxik]

I am not saying it have to be removed after installation. I just don't need it for runtime. This is useful for Fedora packages, since we install the build dependency just during the build of the package. When our user installs the package, there is no need to have the build time package installed anymore

[copiousfreetime]

@voxik thanks for the clarification, it would definitely make things easier if we just left build dependencies installed. Maybe there could be an uninstall --builddeps or similar option that just uninstalled gems that were only build dependencies for those that want to minimize.

[copiousfreetime]

@flavorjones best way to support would be a pull request with a sample implementation with tests 😄.

[flavorjones]

I've said in the past on this thread and the Nokogiri thread that I still don't understand the compelling reason to implement this. I get that it seems unclean, but having one additional gem installed on one's system doesn't seem to be that big of a deal.

Can someone explain to me what the pain point is, and provide enough detail for me to empathize with the amount of pain you're in?

@copiousfreetime I'm likely not qualified to operate on Rubygems, but understanding why this is important to people might help motivate me.

[copiousfreetime]

@flavorjones I'm going through all the rubygems issues attempting to gauge interest and understand them so we can prioritize and figure out what to work on. So clarifying the problems and making notes on potential approaches to solutions are what I'm doing right now.

Whether or not a pull request will result from this issue, that's another question.