Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fresh install fails due to gemfile version conflict (puma) #226

Open
acbart opened this issue Feb 2, 2023 · 3 comments
Open

Fresh install fails due to gemfile version conflict (puma) #226

acbart opened this issue Feb 2, 2023 · 3 comments

Comments

@acbart
Copy link

acbart commented Feb 2, 2023

Installing CodeWorkout on a fresh server, I got an error with the puma gem:

Bundler could not find compatible versions for gem "puma":
  In snapshot (Gemfile.lock):
    puma (= 4.3.10)

  In Gemfile:
    puma (~> 4.3.5)

    capistrano3-puma was resolved to 6.0.0.beta.1, which depends on
      puma (>= 5.1, < 7.0)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
ERROR: Service 'web' failed to build: The command '/bin/sh -c bundle install' returned a non-zero code: 6

It seems like a straightforward version conflict, but I don't have the experience with Ruby to know which way to resolve the dependency.

@acbart acbart changed the title Fresh install fails due to gemfile Fresh install fails due to gemfile (puma) Feb 2, 2023
@acbart acbart changed the title Fresh install fails due to gemfile (puma) Fresh install fails due to gemfile version conflict (puma) Feb 2, 2023
@s-edwards
Copy link
Member

OK, we'll take a look. Are you trying to install a dev or production setup from source? For development, the docker approach is probably easier. For production use, there's a lot of adjustments/tuning necessary that isn't baked into the source. We're trying to get that into a separate docker image, but don't currently have a student actively working on it.

@acbart
Copy link
Author

acbart commented Feb 2, 2023

We were hoping to use it for production, or at least it was one of the options we wanted to consider. We have a pretty short turn-around time, unfortunately, so if it's too tall a lift then it might be better for us to keep shopping around..?

@s-edwards
Copy link
Member

You probably already know that I'm going to suggest that for production, you're better off using our server :-).

Starting a new production server does have a few obstacles. The two biggest are that first, getting a production rails setup going requires some work, and second, your deploy will have no content and you'll need to provide all the content from scratch. Using our server overcomes both obstacles pretty nicely, and it's easy for us to provide you with custom key/secret pairs for LTI integration into your own tools (plus, built-in single-sign-on support from that).

Setting up your own production facility is certainly achievable, but it isn't just a brief weekend project, and I normally wouldn't recommend it for someone with no rails production deployment experience. There's a fair amount outside the rails app itself that we've done to get our throughput/reliability and content to where it is ... but none of that is part of the app source.

If you're having login or connectivity issues with our production server, let me know so we can help. If it is local bureaucracy that prevents you from using external tools, then let me know and maybe we can find a way to get you up through docker instead--we can bottle most of the production deployment issues into a docker image, although we haven't had anyone working on it in a while. That's probably the best path to getting a production-ready canned solution that is easy to deploy/maintain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants