How to handle reverse dependencies on unicorn?

[Earlopain]

Hey there, I'm following https://bugs.ruby-lang.org/issues/19057 for updates on unicorn and saw that you created this.

First of all, this is pretty cool regardless of the IO work you are planning to do. Unicorn also doesn't support Rack 3 in a released version which would block me on upgrading to future Rails versions if a new release doesn't happen. Rails plans to drop Rack 2 for 8.X as you know.

Long-term plan is to move away from unicorn to something that is actually well maintained like puma but its not something I can do at the moment so I don't know if that would become an issue for me in the future.

One problem I don't see an immediate solution to are reverse dependencies (see here). From a quick look around, I doesn't seem like I can instruct rubygems to accept a replacement gem for a depenency. I only found your issue on the matter at rubygems/rubygems#1746

So, since I depend on unicorn-worker-killer this isn't actually useable for me. Am I correct in that assesment?

[ioquatix]

One way we can deal with this is using a source block in the gemfile, e.g.

source "GitHub packages url" do
  gem "unicorn"
end

I think we can release to a local package repo under the unicorn-ruby namespace... If you are willing to have a go at setting this up, I'd be happy to add you as an admin to the org.

[Earlopain]

Oh, that's certainly interesting. I didn't know that GitHub offers such a thing. While I haven't used that one yet I'm not a stranger for publishing to GitHub packages in general. This looks like a neat solution to the issue in rubygems in general, it didn't even occur to me that you can just use custom gem servers for this.

Yeah, I can give this a shot. I'll try to cook up some GitHub action to publish to their repo. Thank you for the invite 👍

[ioquatix]

See here:

https://github.com/orgs/unicorn-ruby/packages

Hopefully you can access it. If not, we can update your account to admin of this org.

[ioquatix]

If we can automate it using bake, that would be awesome.

https://github.com/ioquatix/bake-gem

[Earlopain]

Yeah, I see that page. It should be good, probably. I'll be experimenting on my fork anyways so it shouldn't matter that much I think.

I can give your gem a try but I wonder how well that will work here, there's no commited version file for example. Unless it's fine to diverge from upstream for this? I didn't plan on making any changes if I can help it.

Any idea what's going on with the actions here? The one on master only ran two checks and seems to be stuck.

[ioquatix]

I think GH actions decided to go on holiday...

I think either way works (diverge, not diverge). Maybe for a first pass we can keep things as simple as possible, just to get something released and usable, then see if there is any interest. Making the code base more maintainable wouldn't be bad if there was value in doing so, but at that point we'd be diverging.

[Earlopain]

Well, I'm pretty disappointed in the GitHub packages repo.

You need an access token to publish, install, and delete private, internal, and public packages.

So, you need auth not only to publish but also when pulling, even if the package is public. Why anyone would use it for public packages with this limitation is beyond me. I've only used the docker one before which doesn't have this problem but apparently all the others do.

I got it working but this seems like a dealbreaker to me. I'd be better off inlining the worker killer implementation.

Would you be opposed to also pulling in unicorn-worker-killer to the org and publish to rubygems? There aren't that many popular gems that depend on unicorn, I would only consider unicorn-rails as another potential candidate.

[ioquatix]

I don't mind to fork additional dependencies. Maybe we can also give this feedback to GitHub? cc @matthewd

[Earlopain]

@ioquatix could you set up the fork for unicorn-worker-killer and publish a version?

[ioquatix]

Sure.

[ioquatix]

Which one?

• https://github.com/kzk/unicorn-worker-killer
• https://github.com/celsworth/unicorn-worker-killer-2

[Earlopain]

I didn't even know there's two 😅. The first one is fine, that one is majorly more popular.

[ioquatix]

Okay, I forked it here. I'll cut a release.

[byroot]

FYI: rubygems/rfcs#54

[Earlopain]

That would certainly make situations like this easier to handle, lets see how it goes this time around. Thanks for linking that.

@ioquatix I see you already forked at https://github.com/unicorn-ruby/unicorn-worker-killer but made no changes yet. Do you still plan on adopting it for usage with this fork?

[ioquatix]

Yeah I can, I have just been tight on time.

[Earlopain]

That's fine, just checking. I can come back in a few weeks when you hopefully aren't too busy.

[Earlopain]

Well, my personal interest in this has waned significantly since I'm not using unicorn anymore. I didn't really expect to move away so quickly but a more modern fork makes that pretty easy (pitchfork)

I'm just going to close this since I see no point in this anymore (feel free to open if you think otherwise)