Ok, this may be a bit basic, but what are the best practices for
customizing an existing extension?

Here's what I'm thinking:

Fork the repo
clone my fork and setup an upstream remote to the original repo

Now, as I'm making modifications, what's the best work flow? Do I include
my forked repo as a gem in my Gemfile. That means any changes I make to the
extension I have to commit locally and push to my remote repo, then switch
over to my spree app and bundle update gem before I can see the results of
the changes.

Or, do I copy the extension from my cloned local repo directly into my
spree app? That means I reference it in my gemfile using the path, make all
my modifications in this embedded gem, then copy the changes back to my
local repo and push them to my forked repo. Finally I'd have to delete the
copied repo from my spree app and update my gemfile to use my remote forked
repo. This is a lot of work for what might amount to some pretty minor
changes. That also means all my changes are in one commit, unless I take
time to break them up when I'm moving them from the embedded version to the
local repo.

Any other ways to do it? I even considered using 'bundle open extension'.
Can you work directly on a gem that way and see the changes? Then how do I
get those changes to my fork?

So how is everyone else doing it?

Thanks for your help. I'm hoping to give more back to the Spree community!

John

--
You received this message because you are subscribed to the Google Groups "Spree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Nate Lowrie at Mar 22, 2013 at 12:47 pm
    What I do:

    1. Fork the repo you want to modify.
    2. Pull that down locally on your dev machine
    3. Put the gem entry in your gemfile linked to the local path of the gem
    on your dev machine. By specifying a local path, you can change the files
    on your dev machine directly and have the changes show up when you refresh
    the dev server page.
    4. Make your changes. If you want eventually want to submit a pull
    request to the original repo for the changes, create a new branch for the
    feature and put your commits on the new branch.
    5. Once you are satisfied and ready to deploy, push all your changes up
    to your forked repo and switch your gemfile to point to the proper branch
    of your forked repo.



    Regards,

    Nate
    On Friday, March 22, 2013 12:23:05 AM UTC-4, ThumbTackSoftware wrote:

    Ok, this may be a bit basic, but what are the best practices for
    customizing an existing extension?

    Here's what I'm thinking:

    Fork the repo
    clone my fork and setup an upstream remote to the original repo

    Now, as I'm making modifications, what's the best work flow? Do I include
    my forked repo as a gem in my Gemfile. That means any changes I make to the
    extension I have to commit locally and push to my remote repo, then switch
    over to my spree app and bundle update gem before I can see the results of
    the changes.

    Or, do I copy the extension from my cloned local repo directly into my
    spree app? That means I reference it in my gemfile using the path, make all
    my modifications in this embedded gem, then copy the changes back to my
    local repo and push them to my forked repo. Finally I'd have to delete the
    copied repo from my spree app and update my gemfile to use my remote forked
    repo. This is a lot of work for what might amount to some pretty minor
    changes. That also means all my changes are in one commit, unless I take
    time to break them up when I'm moving them from the embedded version to the
    local repo.

    Any other ways to do it? I even considered using 'bundle open extension'.
    Can you work directly on a gem that way and see the changes? Then how do I
    get those changes to my fork?

    So how is everyone else doing it?

    Thanks for your help. I'm hoping to give more back to the Spree community!

    John
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • ThumbTackSoftware at Mar 22, 2013 at 12:54 pm
    Thanks Nate. I think the piece I was missing is with path in the gemfile.
    For some reason I thought that had to be within your repo, but it can be
    anywhere on your system, is that correct?
    On Friday, March 22, 2013 8:47:37 AM UTC-4, Nate Lowrie wrote:

    What I do:

    1. Fork the repo you want to modify.
    2. Pull that down locally on your dev machine
    3. Put the gem entry in your gemfile linked to the local path of the
    gem on your dev machine. By specifying a local path, you can change the
    files on your dev machine directly and have the changes show up when you
    refresh the dev server page.
    4. Make your changes. If you want eventually want to submit a pull
    request to the original repo for the changes, create a new branch for the
    feature and put your commits on the new branch.
    5. Once you are satisfied and ready to deploy, push all your changes
    up to your forked repo and switch your gemfile to point to the proper
    branch of your forked repo.



    Regards,

    Nate
    On Friday, March 22, 2013 12:23:05 AM UTC-4, ThumbTackSoftware wrote:

    Ok, this may be a bit basic, but what are the best practices for
    customizing an existing extension?

    Here's what I'm thinking:

    Fork the repo
    clone my fork and setup an upstream remote to the original repo

    Now, as I'm making modifications, what's the best work flow? Do I include
    my forked repo as a gem in my Gemfile. That means any changes I make to the
    extension I have to commit locally and push to my remote repo, then switch
    over to my spree app and bundle update gem before I can see the results of
    the changes.

    Or, do I copy the extension from my cloned local repo directly into my
    spree app? That means I reference it in my gemfile using the path, make all
    my modifications in this embedded gem, then copy the changes back to my
    local repo and push them to my forked repo. Finally I'd have to delete the
    copied repo from my spree app and update my gemfile to use my remote forked
    repo. This is a lot of work for what might amount to some pretty minor
    changes. That also means all my changes are in one commit, unless I take
    time to break them up when I'm moving them from the embedded version to the
    local repo.

    Any other ways to do it? I even considered using 'bundle open extension'.
    Can you work directly on a gem that way and see the changes? Then how do I
    get those changes to my fork?

    So how is everyone else doing it?

    Thanks for your help. I'm hoping to give more back to the Spree community!

    John
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nate Lowrie at Mar 22, 2013 at 1:14 pm
    From the Bundler Docs:

    If you are actively developing a gem, perhaps checked out from Github, you
    can use the gem directly from its directory on your filesystem.

    gem 'nokogiri', :path => '~/sw/gems/nokogiri'


    See http://gembundler.com/v1.3/gemfile.html

    Regards,

    Nate
    On Friday, March 22, 2013 8:54:04 AM UTC-4, ThumbTackSoftware wrote:

    Thanks Nate. I think the piece I was missing is with path in the gemfile.
    For some reason I thought that had to be within your repo, but it can be
    anywhere on your system, is that correct?
    On Friday, March 22, 2013 8:47:37 AM UTC-4, Nate Lowrie wrote:

    What I do:

    1. Fork the repo you want to modify.
    2. Pull that down locally on your dev machine
    3. Put the gem entry in your gemfile linked to the local path of the
    gem on your dev machine. By specifying a local path, you can change the
    files on your dev machine directly and have the changes show up when you
    refresh the dev server page.
    4. Make your changes. If you want eventually want to submit a pull
    request to the original repo for the changes, create a new branch for the
    feature and put your commits on the new branch.
    5. Once you are satisfied and ready to deploy, push all your changes
    up to your forked repo and switch your gemfile to point to the proper
    branch of your forked repo.



    Regards,

    Nate
    On Friday, March 22, 2013 12:23:05 AM UTC-4, ThumbTackSoftware wrote:

    Ok, this may be a bit basic, but what are the best practices for
    customizing an existing extension?

    Here's what I'm thinking:

    Fork the repo
    clone my fork and setup an upstream remote to the original repo

    Now, as I'm making modifications, what's the best work flow? Do I
    include my forked repo as a gem in my Gemfile. That means any changes I
    make to the extension I have to commit locally and push to my remote repo,
    then switch over to my spree app and bundle update gem before I can see the
    results of the changes.

    Or, do I copy the extension from my cloned local repo directly into my
    spree app? That means I reference it in my gemfile using the path, make all
    my modifications in this embedded gem, then copy the changes back to my
    local repo and push them to my forked repo. Finally I'd have to delete the
    copied repo from my spree app and update my gemfile to use my remote forked
    repo. This is a lot of work for what might amount to some pretty minor
    changes. That also means all my changes are in one commit, unless I take
    time to break them up when I'm moving them from the embedded version to the
    local repo.

    Any other ways to do it? I even considered using 'bundle open
    extension'. Can you work directly on a gem that way and see the changes?
    Then how do I get those changes to my fork?

    So how is everyone else doing it?

    Thanks for your help. I'm hoping to give more back to the Spree
    community!

    John
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • ThumbTackSoftware at Mar 22, 2013 at 5:25 pm
    Ah, RTFM. Thanks for your help Nate!

    John
    On Friday, March 22, 2013 9:14:53 AM UTC-4, Nate Lowrie wrote:

    From the Bundler Docs:

    If you are actively developing a gem, perhaps checked out from Github, you
    can use the gem directly from its directory on your filesystem.

    gem 'nokogiri', :path => '~/sw/gems/nokogiri'


    See http://gembundler.com/v1.3/gemfile.html

    Regards,

    Nate
    On Friday, March 22, 2013 8:54:04 AM UTC-4, ThumbTackSoftware wrote:

    Thanks Nate. I think the piece I was missing is with path in the gemfile.
    For some reason I thought that had to be within your repo, but it can be
    anywhere on your system, is that correct?
    On Friday, March 22, 2013 8:47:37 AM UTC-4, Nate Lowrie wrote:

    What I do:

    1. Fork the repo you want to modify.
    2. Pull that down locally on your dev machine
    3. Put the gem entry in your gemfile linked to the local path of the
    gem on your dev machine. By specifying a local path, you can change the
    files on your dev machine directly and have the changes show up when you
    refresh the dev server page.
    4. Make your changes. If you want eventually want to submit a pull
    request to the original repo for the changes, create a new branch for the
    feature and put your commits on the new branch.
    5. Once you are satisfied and ready to deploy, push all your changes
    up to your forked repo and switch your gemfile to point to the proper
    branch of your forked repo.



    Regards,

    Nate
    On Friday, March 22, 2013 12:23:05 AM UTC-4, ThumbTackSoftware wrote:

    Ok, this may be a bit basic, but what are the best practices for
    customizing an existing extension?

    Here's what I'm thinking:

    Fork the repo
    clone my fork and setup an upstream remote to the original repo

    Now, as I'm making modifications, what's the best work flow? Do I
    include my forked repo as a gem in my Gemfile. That means any changes I
    make to the extension I have to commit locally and push to my remote repo,
    then switch over to my spree app and bundle update gem before I can see the
    results of the changes.

    Or, do I copy the extension from my cloned local repo directly into my
    spree app? That means I reference it in my gemfile using the path, make all
    my modifications in this embedded gem, then copy the changes back to my
    local repo and push them to my forked repo. Finally I'd have to delete the
    copied repo from my spree app and update my gemfile to use my remote forked
    repo. This is a lot of work for what might amount to some pretty minor
    changes. That also means all my changes are in one commit, unless I take
    time to break them up when I'm moving them from the embedded version to the
    local repo.

    Any other ways to do it? I even considered using 'bundle open
    extension'. Can you work directly on a gem that way and see the changes?
    Then how do I get those changes to my fork?

    So how is everyone else doing it?

    Thanks for your help. I'm hoping to give more back to the Spree
    community!

    John
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupspree-user @
categoriesrubyonrails
postedMar 22, '13 at 4:23a
activeMar 22, '13 at 5:25p
posts5
users2
websitespreecommerce.com
irc#RubyOnRails

2 users in discussion

ThumbTackSoftware: 3 posts Nate Lowrie: 2 posts

People

Translate

site design / logo © 2022 Grokbase