On 09/14/2015 07:08 AM, Josef Stribny wrote:
On 09/12/2015 12:41 AM, Jóhann B. Guðmundsson wrote:
On 09/11/2015 09:09 PM, Orion Poplawski wrote:
What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails"
and "pip
install ipython"?
This indeed is very good question.
I'm not sure how things are elsewhere in the world but in the case of
gem's on a rock in the middle of the north atlantic ocean , everybody
is using bundler with nobody wanting to go back to non existing or
not current gem's in distributions and or having to manually chase
down components and resolve their dependency's.
They prefer spending that time actually hacking or drinking beer or
both.
JBG
I would argue that the most valuable thing apart from the security
tracking is that you can properly specify _all_ dependencies the gem
actually have. This is a big one for at least few reasons:
1, end-users don't have to go read README to know what to install so
that the software actually starts working
2, avoids compilation errors due to the missing header files or conflicts
3, installation is faster and more predictable
If someone has a problem with installing a gem, he/she can install
rubygem-* package on Fedora and it's done (they can easily combine
them with upstream gems). It's also quite nice that a beginner can
just dnf install some framework if he just want to quickly try/evalute
it, but does not want to spend afternoon hunting installation issues.
This seems less relevant for experience people, e.g. I know how to fix
problems with Ruby, but when I need to do a little of Python work I
prefer to install Fedora packages rather than trying to make pip work
for me.
But generally there are other (small) things as well...you don't need
to install any junk like -devel packages on your system, you can track
all your software with rpm/dnf (e.g. you can rollback a transaction),
the gem can come with man pages, etc.
Perhaps in the past that workflow you point out here above was relevant
( to the "market" ) but people and companies ( here ) want to deploy
Rails app to a container ( usually docker ) or a vm which has all of the
app’s dependencies ( and they are using bundler for that application
itself ) fully test the app in the container ( or a vm ), then ship the
container ( or the vm ) to their production host(s) and or make
available for their customers or the end users to use when they are
ready and stick to supporting that container ( or vm ) image/setup only
( which addresses completely your 1,2,3 points there ) not the
gazillion linux distribution out there and their package management
system and formats apt, aptitude dselect ubuntu software
center,dnf,yum,apt-rpm,poldek, up2date, urpmi,
zypp,slapt-get,slackpkg,zendo,netpkg,swaret,appbrowser,
conary,equo,pkgutils,pacman petget, pisi,portage smart package
manager, steam,tazpkg, upkg ( and probably bunch of others that I have
forgot to mention ) and the downstream distribution policy's that go
along with them.
Sorry to say but developers and companies here ( perhaps elsewhere as
well ), have had their fill with Linux, it's fragmentation and it's
freedoom of choice and trying to support all that ( and I can fully
understand them ).
They simply have welcomed their new container overlords and are using
only the recommended upstream method for installing for their
application ( pip,gem etc since developers can use the upstream support
community for those ) in those container images, followed by a strong
attitude of use it ( their produced container/vm image not some
downstream shipped/provided "package" ) or "take your freedom of choice
and get lost, we are done trying to support and play the "X-factor of
linux distributions" game. "
And once the "market" has ( started ) taken a stance ( moving away from
downstream provided package of their components since it does not work
due to the fragmentation in the linux ecosystem ) it's irrelevant what I
think or you think or distributions think or implement locally beside
providing the underlying structure to run their application for the sole
purpose of being relevant as an platform for deployment ( which today is
basically any distribution that ships systemd ).
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct