2012-08-08 51 views
0

我正在使用一個由一個主寶石(我們稱之爲SuperGem)和幾個它所依賴的小寶石組成的ruby項目。該項目在Github上,我分叉它並維護我自己的版本(稱爲SuperGemFork)。當SuperGem更新時,我只需要拉和合並新代碼,然後更新SuperGemFork上的版本號。維護分叉寶石和分叉依賴項

現在就是這種情況。我也想製作我自己的一個版本的依賴項(我們稱之爲SmallGem)。所以現在我想要SuperGemFork依靠SmallGemFork而不是SmallGem。因此,當SuperGem和SmallGem都更新時,我現在必須將兩個gem中的代碼合併到我的叉中,更新版本號並更改SuperGemFork中的依賴關係以依賴SmallGemFork的新版本。

我的問題是不得不改變SuperGemFork中的依賴關係。當SuperGem(原始版本)更新時,它現在取決於新版本的SmallGem。但是,如果我從兩個gem中提取併合並代碼,但忘記更新依賴項,則即使存在新版本,SuperGemFork仍依賴於SmallGemFork的舊版本。不得不改變依賴關係是多餘的並且容易出錯,並且我想至少在我運行bundle install時發生某些失敗,或者如果我忘記這樣做,則啓動應用程序。

那麼,有沒有一種很好的方式可以讓我輕鬆地維護自己的分支之間的依賴關係?

謝謝, 亞歷克斯

回答

0

如果有可能的猴子修補原來的寶石,而不是重寫源代碼,我會走那條路。這是Ruby的強項之一。

然後,他們可以更改他們的代碼,並且不會像源代碼那樣緊密地耦合到源代碼的物理佈局,因爲您將實際的邏輯和它們創建的對象。

+0

的確如此,如果我通過monkey-patching重寫我的gem版本中的某個函數,但我只想對該函數進行一些小修改,那麼我基本上必須將原始代碼複製並粘貼到我的寶石。然後,當原始寶石中的功能發生變化時,沒有簡單的方法來檢測並將更改合併到我的版本中。我非常喜歡猴子修補的想法,因爲它使得依賴關係更加清潔,但它似乎會使開發變得更加困難。你怎麼看? – alexsanford1 2012-08-09 01:16:16

+0

根據我的經驗,當你使用猴子補丁的時候有一些代碼重疊,但是它比分支整個寶石要少很多。我認爲利用Ruby的覆蓋方法的能力有所幫助。這不是一個容易的任務,但你有一些前途。 – 2012-08-09 07:29:40

+0

感謝您的幫助!它看起來沒有其他答案,所以我會接受這個答案。它看起來像是分叉或是猴子修補,每種都有優點和缺點。 – alexsanford1 2012-08-15 11:46:01