Announcement

Collapse
No announcement yet.

Ruby on Rails 6.0 Slated For Fedora 33

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ruby on Rails 6.0 Slated For Fedora 33

    Phoronix: Ruby on Rails 6.0 Slated For Fedora 33

    Fedora 33 is already set to be one of their largest releases ever and it's only getting bigger...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    As a (formerly full-time) Ruby developer, I find it odd that distros package this at all. Although it somewhat frustrates me as a distro developer myself, even I wouldn't use a distro package when developing a Ruby application. Even Fedora moves too slowly to keep up with the ecosystem and the tooling isn't designed to work this way either so the distro just ends up getting in the way. The only reason why you might want it as a package is for other end-user packages that require it. In this case, there's only Redmine. It's still developed but it's never been particularly popular.

    Comment


    • #3
      would suse be a different case - in that i think they use it in YaST?

      Comment


      • #4
        Originally posted by Jedibeeftrix View Post
        would suse be a different case - in that i think they use it in YaST?
        I know YaST uses Ruby but I don't think it uses Rails.

        Comment


        • #5
          Yeah, you can just download the gem right? More up to date and no issues otherwise.

          Comment


          • #6
            Originally posted by Chewi View Post
            As a (formerly full-time) Ruby developer, I find it odd that distros package this at all. Although it somewhat frustrates me as a distro developer myself, even I wouldn't use a distro package when developing a Ruby application. Even Fedora moves too slowly to keep up with the ecosystem and the tooling isn't designed to work this way either so the distro just ends up getting in the way. The only reason why you might want it as a package is for other end-user packages that require it. In this case, there's only Redmine. It's still developed but it's never been particularly popular.
            What about packaging it for rolling release distros like Arch or Void? They are very fast to package updates.

            Comment


            • #7
              Originally posted by Vistaus View Post

              What about packaging it for rolling release distros like Arch or Void? They are very fast to package updates.
              Gentoo is my distribution and yes, our Rails package is up to date for the same reason, but I doubt I could say that about all our Ruby packages. Almost every Rails project will likely pull in some relatively obscure gem that is either outdated or isn't packaged at all. If you have to rely on RubyGems for even one gem then what's the point? What do you gain from using packages in this context anyway? You can't build Ruby code with optimisations. Most gems with native code will build from source and honour CFLAGS anyway. One of Gentoo's best features is USE flags but they're not that useful here either.

              Comment


              • #8
                Debian also package symfony, laravel, a whole host of php libs you'd normally install via composer (php's dependency manager) and the same goes for node and a ton of random libs you'd normally install via npm/yarn.

                Python too, but I do understand it as so much system tooling is written in python.

                Comment


                • #9
                  I'm not familiar with those libraries but at least in PHP's case, there are more popular end-user applications. I maintain phpBB and TT-RSS, for instance, although they do not have any dependencies beyond PHP itself.

                  Comment


                  • #10
                    Where is Ruby compared to Python these days WRT to actual useage ?
                    It seems to me that the Python is prevailing in segment of interpreted languages that are not bound to VM ( as Javascript etc)...



                    Comment

                    Working...
                    X