search

ui-alchemy / ui_alchemy-rails

http://www.ui-alchemy.org
MIT License
14 stars 21 forks source link

Investigate Packaging as a Gem #56

Closed ehelms closed 11 years ago

ehelms commented 12 years ago

I have been doing some reading, investigating and thinking and have come down to a few ways to approach turning this into a gem. No matter what route, we will be able to easily in our project Gemfiles locally pull down ConvergeUI and edit it dynamically or allow those who don't care but need to use the gem to install it from rubygems.org. Here are our options as I see them currently:

Option 1: Straight Gem

This option is simply taking what we have and wrapping it up as a standard and simple gem.

Pros:

Cons:

Option 2: Pure Rails Engine

This option moves ConvergeUI to be packaged from head-to-toe as a rails engine.

Pros:

Cons:

Option 3: Hybrid Approach

This similar to how pure gems are made available to Rails projects. Two separate gems are created, a simple gem and a Rails engine. Examples are minitest and minitest-rails, compass and compass-rails, sass and sass-rails.

Pros:

Cons:

jtomasek commented 12 years ago

For me the Rails Engine (option 2) is the way to go. With the depth we want to go with the Converge-UI we will probably be dependent on Rails ( I see some dependency in Login now ).

With the Hybrid approach I am not sure if it is worth the effort in this case. It would require maintaining two gems as well as deciding which converge-ui functionality/assets would be included in which gem and if it would work in synergy. (eg. Here is the login functionality in cui-rails gem, backed up by assets from cui gem but some of the login related assets are not usable without the cui-rails gem so they should be only in cui-rails gem ...)

knowncitizen commented 12 years ago

Agreed. I see no reason to not tie this to Rails. If demand for another type of engine or framework increases, we could consider porting it. As is, haml and sass are largely a Ruby/Rails thing. (Sinatra uses haml as well).

ehelms commented 12 years ago

Right now the only piece that is dependent upon rails is the views that we supply and only because we use some of the automatic form generation calls that are specific to rails. Everything else - images, fonts, stylesheets, and javascript are independent of Rails specifically. HAML and SASS are largely Ruby things because that is how they were originally used and packaged, but even they provide both a basic ruby gem version and a rails integration gem. I have used HAML and SASS in Python web apps though.

As far as I know, a Sinatra application (which for the record, there is one that has floated the idea of using CUI but I think has just been quite busy with other things) cannot consume a Rails engine.

On Mon, Oct 22, 2012 at 8:56 AM, Jason E. Rist notifications@github.comwrote:

Agreed. I see no reason to not tie this to Rails. If demand for another type of engine or framework increases, we could consider porting it. As is, haml and sass are largely a Ruby/Rails thing. (Sinatra uses haml as well).

— Reply to this email directly or view it on GitHubhttps://github.com/Katello/converge-ui/issues/56#issuecomment-9662550.

Go Pack and War Eagle, Eric D. Helms

Ph.D. Student - North Carolina State University

jtomasek commented 12 years ago

How about templating - content_for, yields and partials? That is also Ruby/Rails specific, isn't it? It can be used in Sinatra with some effort but anyway...

ehelms commented 12 years ago

Good call, I forgot about those constructs as well being tied to Rails in the views.

On Mon, Oct 22, 2012 at 10:13 AM, Jirka Tomasek notifications@github.comwrote:

How about templating - content_for, yields and partials? That is also Ruby/Rails specific, isn't it? It can be used in Sinatra with some effort but anyway...

— Reply to this email directly or view it on GitHubhttps://github.com/Katello/converge-ui/issues/56#issuecomment-9665055.

Go Pack and War Eagle, Eric D. Helms

Ph.D. Student - North Carolina State University

ehelms commented 11 years ago

Update: After the switch to the new organization, I took a few hours to investigate packaging alchemy as a Rails engine and subsequently how to pair that up with the example application. First off you can find my work here:

https://github.com/ehelms/alchemy/tree/engine https://github.com/ehelms/converge-ui-example/tree/engine

Things to Note:

ehelms commented 11 years ago

Update and Integration Plan:

Work has been done by @jtomasek to integrate the engine version of Alchemy using the asset pipeline into Conductor and everything appears to be working well. That being the case, and since Katello can continue to use the engine version as a git submodule with updated pathing, I propose the following to switch us to the enginified version of Alchemy:

  1. @knowncitizen will open 1+ pull requests to fix up some work from his converge_updates in Katello
  2. All open pull requests (@knowncitizen + @jtomasek) will be promptly dealt with merged.
  3. There will be a freeze on new PRs.
  4. I will merge in newest to my engine branch, fix and open a PR to Alchemy master.
  5. Review engine PR.
  6. After merge, Katello side will update git submodule, symlinks and Jammit paths.
  7. After merge, Conductor will be able to use engine as both a gem and in development mode.

If there are any questions, or concerns, speak now or forever hold your peace.

ehelms commented 11 years ago

Resolved as of: https://github.com/ui-alchemy/alchemy/pull/123