<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 18, 2014 at 5:55 AM, Mo Morsi <span dir="ltr"><<a href="mailto:mmorsi@redhat.com" target="_blank">mmorsi@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
<div>On 01/18/2014 01:40 AM, Michael Stahnke
wrote:<br>
</div>
<blockquote type="cite">
<pre>On Fri, Jan 17, 2014 at 6:53 PM, Rahul Sundaram <a href="mailto:metherid@gmail.com" target="_blank"><metherid@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre>Hi
On Fri, Jan 17, 2014 at 9:43 PM, Mo Morsi wrote:
</pre>
<blockquote type="cite">
<pre>Yes as others have mentioned puppet requires ruby(release) which is
satisfied by both ruby-mri and jruby
</pre>
</blockquote>
</blockquote>
<pre>So should it just require ruby-mri?
The divergence from the way upstreams handle ruby here is quite
difficult to work with. I find ruby-pick and bundler patching to be
less fun/friendly than having what I'd expect form upstream. I'm not
in love with the way upstream handles/does things, but I don't really
understand what happened to the 'upstream first' mantra. Here we
(Fedora) just made up their own rules and moved forward.
</pre>
</blockquote>
</div><p> <br>
Could you elaborate on what the difficulty is? Just curious as to
what issues there are.<br></p></div></blockquote><div>I've had issues in the past with Ruby pick when it was first being developed. I know some apps (and possibly some gems) expected env ruby to eval to a ruby and not ruby-pick shell helpers. That may not be the case any more, as I haven't run into that in a while. (Though I don't always use the Fedora ruby any more either). </div>
<div><br></div><div>I remember having to unpatch bundler to do what I wanted. Now, I basically hate bundler, but when it works differently on Fedora than it does on other platforms that only makes it worse. </div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>Completely agree that the current Fedora/Ruby integration is not
ideal, it is a work in progress afterall. That being said upstream
Ruby practices and downstream Fedora guidelines do take different
approaches to many various things, eg just the existence of
bundler is counter to Fedora's 'no-vendored-deps' policy. So
compromises will have to be made at some level.<br>
<br></p></div></blockquote><div>Yes, bundler is counter to the the philosophy. So is golang. Sadly, people spend person-years redoing this work then with statically linked or bundled stuff. I don't love it at all, but I do see big upticks in all-in-one packages (omnibus, fpm, etc) in the community -- at least around configuration/cloud automation. And they all complain about distro packaging because of maintainers modifying upstream behavior. This is normally a larger issue on other distros (not Fedora), but we are not immune to it. </div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>
</p>
<p>We try our best to make everyone happy, providing as much of the
flexibility associated with upstream Ruby practices that we can
while still adhering to Fedora's principles and strategies. Now if
we could install multiple versions of a rubygem rpm via yum,
that'd help us out a bit.....<br>
</p><div class="im">
<br>
<blockquote type="cite">
<blockquote type="cite">
<pre>... which is fine. However yum install puppet should be pulling in only
one. Not both. I would say almost everybody would expect that to be
ruby-mri
</pre>
</blockquote>
<pre>I would say exactly everybody, since on jruby there are issues.
</pre>
</blockquote>
<br>
</div><p>Didn't know puppet didn't work on JRuby, what about the other
Ruby interpreters such as Rubinius? If MRI is the only supported
solution for Puppet, then yes I'd agree that specific dep should
be there (though am not the package maintainer myself), but if it
can work against multiple backends then why not let the user
decide?</p></div></blockquote><div><br></div><div>We (Puppet Labs) tries to keep test passing in Jruby, but there a few bugs. I think master side it works ok, unless you have providers that use C extension gems. Agent side, we do no testing of running on Jruby. We'll be doing much more with Jruby master side in the future, so those bugs (if they haven't already been) should be worked out soon. </div>
<div><br></div><div>We don't test rubinius, but we have a few fans of it here. I'd be curious if our spec tests pass on that. I'd be happy to look into those details more, but we should probably move the conversation to a different thread. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p><span class="HOEnZb"><font color="#888888"><br>
</font></span></p><span class="HOEnZb"><font color="#888888">
<p> -Mo<br>
</p>
</font></span></div>
<br>--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a><br></blockquote></div><br></div></div>