Any examples of Github projects with a main library and derivatives?
November 27, 2012 9:30 AM
I want to create a github project consisting of a main library with derivative variations, such as Drupal and Wordpress plugins. Can you point me to existing projects with this kind of structure? I'd love to learn from existing projects that do it well.
I'm interested in creating a github project that takes text input - for example, an article or a blog post - and outputs a list of keywords or topics ... a bit like a concordance generator.
I've never created a structured project like this before, and I'd love to learn from existing projects that do it well.
I'd like to make it flexible without falling into the trap of the never-completed too-many-options project.
Can you point me to existing github projects that have a similar approach and structure - a main set of functionality, probably as a library, but with derivative versions such as CMS plugins (Drupal, Wordpress, etc)?
PHP would be great, but other languages would be okay too.
Links to any resources that would be helpful or guidelines for best practices would also be most welcome.
Thanks!
I'm interested in creating a github project that takes text input - for example, an article or a blog post - and outputs a list of keywords or topics ... a bit like a concordance generator.
I've never created a structured project like this before, and I'd love to learn from existing projects that do it well.
I'd like to make it flexible without falling into the trap of the never-completed too-many-options project.
Can you point me to existing github projects that have a similar approach and structure - a main set of functionality, probably as a library, but with derivative versions such as CMS plugins (Drupal, Wordpress, etc)?
PHP would be great, but other languages would be okay too.
Links to any resources that would be helpful or guidelines for best practices would also be most welcome.
Thanks!
Well, you could also have a much simpler structure where the generator functionality is contained in a single file which is then used by the WordPress, Drupal, et al, plugins. The plugins are simply context-specific shells around the core functionality.
Alternatively if you want to have simpler downloads/packages, such as per context ones, where only the files needed for that context are included, with the same separation of concerns as suggested previously. You'd create multiple repos and include the core functionality (which is in its own repo) as a submodule to all the other. I did this last week with an app and it worked nicely.
posted by billsaysthis at 9:52 AM on November 27, 2012
Alternatively if you want to have simpler downloads/packages, such as per context ones, where only the files needed for that context are included, with the same separation of concerns as suggested previously. You'd create multiple repos and include the core functionality (which is in its own repo) as a submodule to all the other. I did this last week with an app and it worked nicely.
posted by billsaysthis at 9:52 AM on November 27, 2012
If you prefer a more inter-related approach, setup the main library as the master branch of the overall project. Then for each cms, placed within a subdirectory of the main library, add it as a submodule to the main project. This, in my opinion, makes it more clear that the CMS modules are a "part" of the main library and not the reverse.
For checking out local copies, you would run your normal
'git clone [url for origin repo]'
and then as an additional step from the same directory run
'git submodule update --init'
The latter checks out all the submodules of the main repository. Changes to submodules are pushed by first changing to the submodule directory and issuing your commit and push commands there; your git configuration is (normally) smart enough to figure out you want to update the submodule and not the parent repo.
posted by schade at 2:15 PM on November 27, 2012
For checking out local copies, you would run your normal
'git clone [url for origin repo]'
and then as an additional step from the same directory run
'git submodule update --init'
The latter checks out all the submodules of the main repository. Changes to submodules are pushed by first changing to the submodule directory and issuing your commit and push commands there; your git configuration is (normally) smart enough to figure out you want to update the submodule and not the parent repo.
posted by schade at 2:15 PM on November 27, 2012
This thread is closed to new comments.
Not sure how familiar you are with git but that seems key. I haven't used Wingman but it seems like it would help you streamline the workflow and make organization a little more manageable.
posted by special-k at 9:40 AM on November 27, 2012