Why not update instead? and cc the maintainer?

Hmmm... I'm a bit confused, honestly. In the first place, why are there two different ways of packaging ruby packages? There are ruby applications much less used that rails, for example taskjuggler, which are packaged under the top namespace. On the other side, rails is under rubyPackages_x_x namespace. On top of that, reading at the docs it seems that bundix is the current recommended way. Does it make sense adding this package through bundix and depreciating the one in rubyPackages_x_x?

TBH I have less knowledge then you. But, as in other packages sets, such as pythonPackages, I think a package you create using bundix is added to the rubyPackages_x_x set by adding it to a ruby-packages.nix file - I think it's this one:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/ruby-packages.nix

In the first place, why are there two different ways of packaging ruby packages?

@waiting-for-dev the ruby section document explain the differences https://github.com/NixOS/nixpkgs/blob/e16df73d3040526fdf5f6a34adae79dedb0387ba/doc/languages-frameworks/ruby.section.md. In this case you need to update the default gemset, in order to update rails.

For rails development, I recommend to use bundlerEnv with nix-shell

Thanks for pointing me out that documentation @marsam . TBH I hadn't seen it before.

In the nixpkgs tree, Ruby packages can be found throughout, depending on what they do, and are called from the main package set. Ruby gems, however are separate sets, and there's one default set for each interpreter (currently MRI only).

I'm still confused... I guess that for Ruby package we understand any Ruby program which hasn't been packed as a gem by its developers... Anyway, I'm not sure it's a consistent differentiation right now. For example, rubocop is a gem, and it appears twice in nixpkgs collection: one in ruby-packages and another one as a regular package.

I'm trying to update rails through ./maintainers/scripts/update-ruby-packages script, while at the same time I'm learning how this process works. Unless I'm missing something I think it works in a very unsustainable way.

According to my understanding, all gems that will be available through ruby.withPackages are taken from pkgs/development/ruby-modules/with-packages/Gemfile. This basically means that each available gem must be compatible with any other gem listed there, even if you're not going to install it ever.

In this case, trying to update rails doesn't go beyond 4.2 version, only because another listed gem called cocoapods depends on activesupport >= 4 < 5, while rails 6 (last version) requires activesupport 6.

I think it's extremely problematic to depend on all gem maintainers keeping its dependencies updated in order to provide updated ruby packages for nix. WDYT?

Yea well, this is one of those issues with Nixpkgs in general that need attention you might want to get attention for in NixOS/rfcs. I don't have a strong opinion here as I'm not familiar with the Rails/Ruby ecosystem in Nixpkgs... Sorry.

Ruby package we understand any Ruby program which hasn't been packed as a gem by its developers

IIUC bundlerApp is meant to be used in applications (provides an executable), and rarely is required, chef is a good example.

For example, rubocop is a gem, and it appears twice in nixpkgs

keep in mind that ruby.withPackages was just recently introduced last september, and the regular rubocop has been there way before.
IMHO we should remove the regular rubocop, with the recent extensions split it became less useful to keep as a single executable.

I think it's extremely problematic to depend on all gem maintainers keeping its dependencies updated in order to provide updated ruby packages for nix. WDYT?

Agree, this is a general issue when maintaining packagesets in nixpkgs, in {python,haskell}-packages we have to keep only one version of each package.
I use bundlerEnv to work with rails at work, and tbh I'm not sure if would be useful to add rails as regular expression to nixpkgs.

cc: @manveru would you mind shedding some light on this?

I use bundlerEnv to work with rails at work, and tbh I'm not sure if would be useful to add rails as regular expression to nixpkgs.

The only but not minor benefit would be to be able to execute rails new when you start a fresh new project. Once the project is created, you don't need it anymore. Right now you have to workaround this creating a Gemfile with only rails, then bundix + nix-shell + rails new and bundix + nix-shell again for the new Gemfile, which is a bit of a PAIN :)

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

Still important to me

I use bundlerEnv to work with rails at work, and tbh I'm not sure if would be useful to add rails as regular expression to nixpkgs.

The only but not minor benefit would be to be able to execute rails new when you start a fresh new project. Once the project is created, you don't need it anymore. Right now you have to workaround this creating a Gemfile with only rails, then bundix + nix-shell + rails new and bundix + nix-shell again for the new Gemfile, which is a bit of a PAIN :)

@waiting-for-dev: Have you found a way round the above? I'm still using the workaround you mention above.

I marked this as stale due to inactivity. → More info

Please rebase