Re: Re: Re: F20: Puppet depchain pulls in Java

[Michael Stahnke <stahnma@xxxxxxxxxxxxxx>]

On Sat, Jan 18, 2014 at 5:55 AM, Mo Morsi <mmorsi@xxxxxxxxxx> wrote:

On 01/18/2014 01:40 AM, Michael Stahnke wrote:

On Fri, Jan 17, 2014 at 6:53 PM, Rahul Sundaram <metherid@xxxxxxxxx> wrote:

Hi


On Fri, Jan 17, 2014 at 9:43 PM, Mo Morsi  wrote:

Yes as others have mentioned puppet requires ruby(release) which is
satisfied by both ruby-mri and jruby

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.

Could you elaborate on what the difficulty is? Just curious as to what issues there are.

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). 

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.  

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.

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. 

 

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

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

I would say exactly everybody, since on jruby there are issues.

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?

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. 

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. 

  -Mo

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct