Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release it as a gem on RubyGems #666

Open
vfonic opened this issue Jul 4, 2015 · 16 comments
Open

Release it as a gem on RubyGems #666

vfonic opened this issue Jul 4, 2015 · 16 comments
Labels
Milestone

Comments

@vfonic
Copy link

vfonic commented Jul 4, 2015

Hi Ryan,

Great work!
I've noticed you've released forem v0.0.1 as a gem on RubyGems long time ago.

Why aren't you using that platform to release other versions? It would allow people to build other gems on top of this one (think of forem plugins), and would give more confidence that gem is production ready as it would be easier to lock on certain gem version (I see there are some issues opened related to people upgrading and then having forem not working properly).

Thanks!

@radar
Copy link
Collaborator

radar commented Jul 5, 2015

Hi Viktor,

Thanks for thinking that Forem is ready for production use. I think differently from that. At best, this project is a great example of what a lightweight production-ready forum system COULD act like.

The short version is that I think Forem needs a rewrite. For starters. it's a silly idea to provide views when most people are just going to override them anyway. We could also stand to use better tooling like Sidekiq to process the moderation queue.

imo, Forem should ONLY provide a well documented JSON API and perhaps some equivalent of Apple's Human Interface Guidelines. The web is moving to JS front ends more and more and I would like Forem to follow that trend. Discourse does it very well imo.

I would like to release a gem to RubyGems, but before that Forem needs to undergo a major transition :)

On 5 Jul 2015, at 05:54, Viktor Fonic [email protected] wrote:

Hi Ryan,

Great work!
I've noticed you've released forem v0.0.1 as a gem on RubyGems long time ago.

Why aren't you using that platform to release other versions? It would allow people to build other gems on top of this one (think of forem plugins), and would give more confidence that gem is production ready as it would be easier to lock on certain gem version (I see there are some issues opened related to people upgrading and then having forem not working properly).

Thanks!


Reply to this email directly or view it on GitHub.

@dt1973
Copy link

dt1973 commented Jul 6, 2015

For starters. it's a silly idea to provide views when most people are just going to override them anyway.

I'm a little bit confused. Isn't that point of the views, to provide a nice and simple foundation with which to override? Unlike Spree's Deface for instance where you have to monkey patch them.

I love the idea of a JSON API, but can't we also provide the views (http://motherfuckingwebsite.com/ style) and possibly ditch the JS / CSS?

The web is moving to JS front ends more and more and I would like Forem to follow that trend. Discourse does it very well imo.

I just started using Discourse and I must say, compared to Forem, it's mess. Way too much stuff, way too many monkey patches, way too difficult to change the layout as you have to relate to both the views and the JS templates.

Plus, it doesn't work as a standalone Rails app (unless you spend days commenting out a lot of stuff). Users are forced to install it via Docker, and if they don't, they don't qualify for help by the Discourse community.

Having said that, Discourse is a GREAT example of things we can copy / paste back into our Forem apps during UI customization.

@yan-hoose
Copy link
Contributor

I agree that the views are useful as a base which you can override, so you don't have to create them from scratch which would take a lot more time. And I like the idea of the views being as simple as possible (plain HTML, no CSS or JS) so you could just copy them to your site and modify with your own HTML/CSS/JS.

Why not release the gem as Forem 1.0 and have the rewrite (if you decide to do it) be 2.0? I guess the rewrite would not happen any time soon anyway, so releasing the current code as 1.0 seems like a decent idea.

@vfonic
Copy link
Author

vfonic commented Jul 7, 2015

Great answers! Thanks, Ryan for taking time to reply.

I agree the gem shouldn't be too HTML/CSS/JS heavy. However, I'd still provide basic front-end, something similar to what Forem offers right now (or Devise or other, non really front-end gems).

I agree with @yan-hoose that this could be released as v1.0 (or v0.1 if you want) and then the rewrite will be the new major version. This would work for both cases, when someone wants to use the gem and for rewrite.

@radar
Copy link
Collaborator

radar commented Jul 12, 2015

I'm a little bit confused. Isn't that point of the views, to provide a nice and simple foundation with which to override?

Yes. I've seen it go bad and I want to prevent that from happening in the future. I concede that it makes more sense to keep the views in the project than to leave them out. The Rails views could be the standard interface for Forem, and then we could have a JSON API that people can use to build a JS version of those "views" themselves.


I want Forem to be improved upon by people who care about having a decent forum system in Rails. I'm happy to participate in that discussion (as self-appointed BDFL), but I don't have time to do much of the coding myself. It seems like just in this issue we have enough people who care about Forem to make it better.

So please, if you find something that you want to improve with Forem, be it adding a JSON API (#665), fixing the failing builds on Travis (finally!), removing the deprecation warnings during the test runs, or improving the layout: please don't be afraid to dig in and help out there.

@radar
Copy link
Collaborator

radar commented Jul 12, 2015

I agree with @yan-hoose that this could be released as v1.0 (or v0.1 if you want) and then the rewrite will be the new major version. This would work for both cases, when someone wants to use the gem and for rewrite.

I guess the whole point of doing this would be to have a version of Forem that is fixed in time? Is that all this will be solving? If so, I'm happy to do a v0.1 release once I get clarification.

@vfonic
Copy link
Author

vfonic commented Jul 12, 2015

Exactly. Have a version that we can refer to and if you use pessimistic
version constraint, you can get any security fixes that get released for
the gem.

I'll have a look this week into the Travis build and see if I can get it to
pass.

On Sun, Jul 12, 2015 at 2:59 AM, Ryan Bigg [email protected] wrote:

I agree with @yan-hoose https://github.com/yan-hoose that this could be
released as v1.0 (or v0.1 if you want) and then the rewrite will be the new
major version. This would work for both cases, when someone wants to use
the gem and for rewrite.

I guess the whole point of doing this would be to have a version of Forem
that is fixed in time? Is that all this will be solving? If so, I'm happy
to do a v0.1 release once I get clarification.


Reply to this email directly or view it on GitHub
#666 (comment).

@eostrom
Copy link

eostrom commented Jul 13, 2015

I love the idea of being able to build JS apps on Forem (I'm depending on making it happen for my current project!) but I don't think Forem should lose the HTML UI entirely. Sometimes you just want to make a Rails app, and Forem was a great way to make that happen on a previous project I worked on.

I've imagined splitting the project into a forem-core gem, a forem-web gem that provides the HTML UI, and a forem-api gem that provides the JSON API. That said, my current thinking is that the API will share some of its controller implementation with the HTML UI, so there may not be enough difference to make it worth splitting into separate gems.

In the near term, I support a 0.1 release to have a version that's fixed in time, to allow security fixes as @vfonic said, and because it's a little faster and more comfortable to integrate gems into a project than GitHub repos. The current gem situation makes Forem look like a Rails 3 project that got abandoned. It may not be 1.0-ready, but it's more stable and useful than that.

Also, releasing a Rails-4-compatible gem might encourage more contributors to help improve it. Speaking of which, thanks, Viktor, for looking into the build problems.

@vfonic
Copy link
Author

vfonic commented Jul 13, 2015

Agree with Erik! I was thinking in the same direction. Let's make
forem-core and, if I get time (really can't promise anything here), I'd
love to make forem-angular as showcase on how to integrate and use API in
your app.

Sorry for brevity. Sent from my phone.

On Monday, July 13, 2015, Erik Ostrom [email protected] wrote:

I love the idea of being able to build JS apps on Forem (I'm depending on
making it happen for my current project!) but I don't think Forem should
lose the HTML UI entirely. Sometimes you just want to make a Rails app, and
Forem was a great way to make that happen on a previous project I worked on.

I've imagined splitting the project into a forem-core gem, a forem-web
gem that provides the HTML UI, and a forem-api gem that provides the JSON
API. That said, my current thinking is that the API will share some of its
controller implementation with the HTML UI, so there may not be enough
difference to make it worth splitting into separate gems.

In the near term, I support a 0.1 release to have a version that's fixed
in time, to allow security fixes as @vfonic https://github.com/vfonic
said, and because it's a little faster and more comfortable to integrate
gems into a project than GitHub repos. The current gem situation makes
Forem look like a Rails 3 project that got abandoned. It may not be
1.0-ready, but it's more stable and useful than that.

Also, releasing a Rails-4-compatible gem might encourage more contributors
to help improve it. Speaking of which, thanks, Viktor, for looking into the
build problems.


Reply to this email directly or view it on GitHub
#666 (comment).

@radar
Copy link
Collaborator

radar commented Jul 13, 2015

Happy to do a v1.0 gem release once the issues in the v1.0 milestone have been addressed.

Get to it :)

@radar radar added this to the v1.0 milestone Jul 13, 2015
@vfonic
Copy link
Author

vfonic commented Jul 15, 2015

Just noticed this is an issue #666 😈

I cloned the repo (finally) and did a checkout of last passing commit. I have some issues getting the dummy data.

spec_helper.rb:3:in `require': cannot load such file -- forem/spec/dummy/config/environment.rb (LoadError)`

@radar Is there some better way for contacting you? Can you provide some dummy data or I missed it somewhere? Should I just try and guess what the data should look like?

The more I dig into this gem, the more I see how much work and time has been put into it. It would really be a shame not to have it released/rewritten as a stable version. Also, the more I dig into it, the more I feel like a lot of parts could be extracted to separate gems like: themes, translations, post formatters, maybe db adapters, etc...

@vfonic
Copy link
Author

vfonic commented Jul 15, 2015

Found the rake task for generating dummy app. # rookie mistake

@vfonic
Copy link
Author

vfonic commented Jul 16, 2015

I've created a PR with passing specs: #670

It's a hack, but it allows us to get to v1.0. Perhaps there are better ways to go around this?

Thinking about releasing v1.0.0 on RubyGems, all other gem dependencies can not be Github dependencies, but should also be released as gems (forem-kramdown, forem-theme-base).

@vfonic
Copy link
Author

vfonic commented Sep 7, 2015

Looks like rails 4.2.4 is out and the issue with counter cache has been fixed. rails/rails#19042

@radar
Copy link
Collaborator

radar commented Sep 7, 2015

Yup, that's fixed now. 1.0 milestone still has issues open. As I said before, once those are fixed then I will do a 1.0 release.

@krainboltgreene
Copy link

I agree significantly with @radar here. I'll start janitoring with this issue in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants