Move template classes out of Tilt
Closed this issue · 15 comments
Is this necessary? From the engines supported in Tilt I maintain Creole and Slim of which Creole doesn't include the Tilt handler while Slim does. The reason is that Slim relies on Tilt and Creole doesn't. For me it doesn't make much of a difference to maintain the Tilt template in Creole as 'creole/template.rb' (which is not required by 'creole.rb').
Well, the biggest problem is supporting multiple versions of other template engines. E.g. RDoc 3.x and RDoc 4.x. It's better if RDoc ships with its own template class that they maintain.
Yes, but some engines might not want to include a tilt template (doesn't rdoc belong to the core libraries?). What is the problem of distinguishing between multiple versions in the tilt implementation?
- The only thing I wouldn't do is to remove existing engines just because they are not externalized
- In principle the transition should be seemless, problems could arise only if people rely on the class names (Tilt::CreoleTemplate) and the external templates live under different namespaces (as it is the case in Slim).
This would prove a big blow to my will to use Tilt. Part of what draws me to Tilt is that it contains all the logic to convert content, and all I need to do is give it a filename and maybe add a gem or two to my Gemfile. The simplicity in its current form is too exceptional to give up, in my opinion.
/cc @benbalter @mattr-
@parkr Not really, since the gem which contains the template engine would also contain the template class. The class is only moved, Tilt would be still equally easy to use. See for example https://github.com/slim-template/slim
@minad Would Tilt's handing of .sass errors remain the same when the gem doesn't exist, such that if I say:
Tilt.new("my_file.sass").renderthen it'll print out a nice error message that instructs the user to install the sass gem?
It will till say LoadError: cannot load such file -- sass, yes. Or, possibly LoadError: cannot load such file -- sass/tilt.
Seems like this really depends on getting the changes in the related projects. Could be as simple as a single PR to each adding the relevant file to their repo.
Anyone want to start?
@judofyr I'm trying to understand your point. Because it's hard to target different major versions of each engine, you want the maintainers of those libraries to be compatible with Tilt. Is it correct?
That means to lock "forever" the interface of Tilt::Template. Right now Tilt supports ~20 engines + a few libs in Ruby stdlib (kudos and thanks for this, btw ✌️ ). If a change in that class is needed, it requires those 20 gems to change accordingly.
What happens if the author of a gem don't to accept your idea? Will that gem no longer compatible with Tilt?
This is a huge change for Tilt, it doesn't change the way it behaves, but it changes a lot in terms of dependencies. If I use Haml, I must be sure to require the version that includes the Tilt template. Should this idea target 3.0 instead of 2.1?
That means to lock "forever" the interface of
Tilt::Template.
Also called a "public API".
If a change in that class is needed, it requires those 20 gems to change accordingly.
What change do you think is needed? Most of the template classes have just the same interface of Tilt for years. Tilt::Template is a very simple API, what makes you think it's going to change majorly soon?
90% of my work on Tilt now is trying to get the build to not fail. Different versions of different template engines support different set of Ruby interpreters, have slightly different output and slightly different API. The main reason I don't do much about Tilt these days is because it takes hour to get a green build.
Maybe we should wait with removing the template classes, but I really like to stop maintaining them.
@judofyr Fair enough, and again, thank you for your effort. 👍
Have you considered to keep the core of Tilt here and extract those templates in external gems like tilt-haml? I've been in a similar burden with Redis::Store, so I decided to have redis-* gems where the version of each of them was the same of the targeting framework. Eg. redis-rack v1.5.0 for rack v1.5.0.
People who needs to use a certain version of a specific engine can point to a well known version of the external lib. Eg in a Gemfile gem 'tilt-builder', '~> 3.2'.
This has the advantage of keeping the build always green. This will help both you with the regular maintenance and devs who want to contribute with pull requests here and in the eventual other gems.
Puuuuuh please don't do this extraction in multiple scattered micro gems as @jodosha suggested! This is so unmaintainable. I agree that there is a lot of effort if all backends are kept in this repository (I do the same with https://github.com/minad/moneta). But @judofyr you also have to see the collective effort of maintaining gems. If you keep it here the maintainance effort in total is lower. You should rather add more maintainers here in this repository and ask for pull requests to make travis happy.
I see your point that it is nice to have other people implementing the tilt interface. However this happens only naturally if one writes a template engine (like Slim) which relies on Tilt by itself or if the maintainer of the other project has a special need for it. But if this is not the case there is no reason to implement the interface. And then the gathering point should be here.
What about creating a single gem called tilt-engines which includes all the
engine classes? That gem would be compatible with both Tilt 1.4 and 2.0.
On lør. 8. nov. 2014 at 12.27 Daniel Mendler notifications@github.com
wrote:
Puuuuuh please don't do this extraction in multiple scattered micro gems
as @jodosha https://github.com/jodosha suggested! This is so
unmaintainable. I agree that there is a lot of effort if all backends are
kept in this repository (I do the same with
https://github.com/minad/moneta). But @judofyr
https://github.com/judofyr you also have to see the collective effort
of maintaining gems. If you keep it here the maintainance effort in total
is lower. You should rather add more maintainers here in this repository
and ask for pull requests to make travis happy.I see your point that it is nice to have other people implementing the
tilt interface. However this happens only naturally if one writes a
template engine (like Slim) which relies on Tilt by itself or if the
maintainer of the other project has a special need for it. But if this is
not the case there is no reason to implement the interface. And then the
gathering point should be here.—
Reply to this email directly or view it on GitHub
#188 (comment).
If you keep it here the maintainance effort in total is lower. You should rather add more maintainers here in this repository and ask for pull requests to make travis happy.
Yes, I think this is the proper solution. I'll open a new issue.