Umgehung des Rack-Versionsfehlers mit Rails 2.3.5

8

Ich bin derzeit auf Dreamhost versucht, eine Rails 2.3.5 App zu starten.

Hier ist die Situation, Dreamhosts Server haben Rails 2.2.2 installiert. Natürlich kann ich die Rails-Version eines freigegebenen Hosts nicht aktualisieren, deshalb habe ich meine Rails im Vendor eingefroren. Rails 2.3.5 benötigt das Rack v1.0.1 gem. Dreamhost verwendet das Rack v1.0.0 gem. Also wenn ich versuche zu definieren:

%Vor%

Ich bekomme:

%Vor%

Was ich also wirklich tun muss, ist die Anforderung meiner App, 1.0.1 zu verwenden, zu umgehen und Dreamhosts 1.0.0 zu verwenden. Kann jemand das konfigurieren? Ist es überhaupt möglich? Danke für die Hilfe.

    
Matthew 29.11.2009, 06:49
quelle

9 Antworten

0

Sie werden fast immer die Edelsteine, von denen Ihre Anwendung abhängt, in den Ordner vendor entpacken. Sie können das mit diesem rake -Befehl tun:

%Vor%

Dies erstellt einen Ordner vendor/gems im Stammverzeichnis Ihrer Anwendung und entpackt alle Edelsteine, die Sie mit dem Befehl config.gem deklariert haben.

Dies löst nicht nur das Problem mit nicht übereinstimmenden rack -Versionen, sondern stellt auch sicher, dass Sie genau die gleichen Versionen von Gems in der Produktion verwenden wie in der Entwicklung, was viele mögliche Kopfschmerzen in der Zukunft verhindern kann.

    
mtyaka 29.11.2009, 08:50
quelle
6

Dreamhost hat dieses Problem jetzt in ihrem Support-Wiki behoben.

Ссылка

Von dieser Seite:

  

Wenn Sie Rails 2.3.5 verwenden, bekommen Sie ein Problem mit dem Namen des Passagiers. Rack 1.0.1 kann nicht geladen werden, da Rack 1.0 bereits aktiviert ist.

     

Eine Möglichkeit, dies zu lösen, ist das Einfrieren von Rails und das Entpacken des Rack-Gems in vendor / gems / rack-1.0.1

     

Sobald sich Rails und Rack im vendor / rails und vendor / gems / rack-1.0.1 befinden, müssen Sie action_controller in der Datei: vendor / rails / actionpack / lib / action_controller.rb

ändern      

In den Zeilennummern 34 und 35 müssen Sie auskommentieren und Folgendes hinzufügen, um das Rack vom Hersteller / den Edelsteinen zu laden:

%Vor%      

Das Endergebnis sollte etwa so aussehen:

%Vor%      

Das eigentliche Problem ist, dass Passenger bereits Rack 1.0 lädt und ich glaube, dass Passenger 1.0.1 laden muss, damit dieser Hack verschwindet.

    
Mike Deck 13.02.2010 07:32
quelle
4

rake gems:unpack:dependencies ermöglicht es Ihnen nicht, Rake in Ihren Vendor / Gems-Ordner zu entpacken.

Für das Dreamhost-Problem musst du tun, was Matt gesagt hat. Freeze Schienen zu 2.3.4.

%Vor%

Dreamhost verwendet eine ältere Version von Passenger, die Rack 1.0.0 vorlädt. Sie können Rack 1.0.1 nicht laden, nachdem Rack 1.0.0 bereits geladen wurde. Daher ist die neueste Version von Schienen, die für DH möglich ist, Rails 2.3.4 und Rack 1.0.0.

    
Henry 17.12.2009 08:15
quelle
1

Ich habe das gleiche Problem beim Upgrade auf 2.3.5 festgestellt.

Ich frage mich, auf welchem ​​Server Sie Rails 2.2.2 laufen lassen? Ich dachte, Dreamhost hätte inzwischen alle auf 2.3.4 gebracht. Ich habe mich vor 3 Monaten bei ihnen beschwert und sie haben Passenger am nächsten Tag auf meinem Server aufgerüstet, damit ich die aktuelle Rails-Version installieren konnte. Ich würde Ihnen daher empfehlen, ein Support-Ticket einzureichen, wenn Rails 2.3.5 für Ihre App wichtig ist. Aber es gab nicht viele Änderungen zwischen 2.3.4 und 2.3.5, also ist die Wahrscheinlichkeit groß, dass Ihre App genauso gut auf 2.3.4 läuft. Hast du versucht, es auf vendored 2.3.4 zu laufen?

Es handelt sich nicht um ein fehlendes Juwel, sondern um ein Juwel, das bei nicht übereinstimmenden Versionen zweimal benötigt wird. Rake Gems: entpacken: Abhängigkeiten nicht beheben (Ich habe es versucht).

Ich vermute, dass es wieder ein Problem mit der Passagierversion von Dreamhost ist. Mein Server (buenosaires) hat Passagier 2.2.5. Neueste Passagier Version ist 2.2.7.

    
anon 30.11.2009 07:07
quelle
1

Ein einfaches Juwel-Update des Racks funktionierte nicht für mich, weil es scheint, dass Rails 2.3.5 speziell Rack 1.0.1 will. Also, als ich einen Edelstein-Update-Rack -v = 1.0.1, Rails 2.3.5 begann direkt.

    
Mike 22.03.2010 15:27
quelle
1

Anscheinend ist die ganze Sache mit Rails, die Rack 1.0.1 wollen, ein kleiner Abhängigkeitsbedarfs-Bug im actionpack, der ziemlich leicht gelöst werden kann.

Für mich war es genug, vendor/rails/actionpack/lib/action_controller.rb in Zeile 34 von gem 'rack', '~> 1.0.1' auf gem 'rack', '~> 1.0' zu bearbeiten und das Problem ging weg.

Siehe: Ссылка

    
dain 25.01.2012 17:36
quelle
0

Dreamhost aktualisiert Rack and Rails: Ссылка

Ich denke, das löst es.

    
someone 18.12.2009 00:05
quelle
0

Ich denke, dass im Moment das Beste wäre, alles aufzutauen und zu nutzen, was auf Dreamhost ist. Sie haben zur Zeit 2.3.4 und wenn du ein oder zwei Tage warten kannst - DreamHost wertet die Rails Gems auf 2.3.5 auf (es sollte bereits gestern am 21. Dezember aktualisiert worden sein - aber aus irgendeinem Grund haben sie es nicht erklärt immer noch auf 2.3.4).

    
Jakub Troszok 22.12.2009 16:22
quelle
0

FWIW, ich kann bestätigen, dass das Einfrieren des Edelsteins das Problem nicht löst; in der Tat, wo vor meinem Einsatz explodierte (mit DH Rack 0.3.0, irgendwie!), jetzt mein Spin-up explodiert mit dem gleichen Fehler oben gesehen. Vielleicht ist es endlich an der Zeit, meine App für Spielzeug / Proof of Concept auf "echtes" Hosting umzustellen, wenn ich etwas erledigen möchte.

UPDATE: Mein Server wurde am 24. Dezember 2009 auf Rack 1.0.1 aktualisiert, um das Problem für mich zu lösen. Wenn weiterhin Probleme mit Ihrem Konto auftreten, empfehle ich die Unterstützung von Messaging. Sie waren in meinem Fall ziemlich reaktionsschnell (mit E-Mails, nicht Aktion, aber für den Preis kann man wirklich nicht alles haben).

    
ragaskar 11.12.2009 15:14
quelle